2011-05-02 8 views
5

Tengo un CMS basado en Rails 3 que permite a los usuarios crear y modificar diseños y vistas. Estos diseños y vistas son los mismos integrados en el marco, solo respaldados por un modelo para algunas capacidades adicionales. El problema que me gustaría abordar es que estos archivos de plantilla se almacenan en caché tan pronto como se acceden al público, por lo que no es posible ver cambios en los diseños o las vistas a menos que se reinicie el servidor. Esto no ocurre en el modo de desarrollo, donde el almacenamiento en caché está deshabilitado, pero, obviamente, desactivar el almacenamiento en caché de plantillas en producción no sería bueno para el rendimiento. Borrar Memcache no parece hacer el truco. ¿Es posible borrar programáticamente la memoria caché de diseños y vistas en producción, quizás con algo así como recargar? como tenemos en la consola? ¿O estoy obligado a tener que reiniciar Passenger cada vez que alguien quiere modificar uno de estos diseños o vistas (tal vez usando el enfoque en este hilo: Rails Cache Clearing)?¿Es posible borrar de forma programática los diseños de Rails 3 y la caché de vistas?

Tenga en cuenta que no me refiero a borrar la página y los cachés de acción, que las páginas públicas confían y funcionan bien.

Respuesta

1

En el modo de producción, es normal que se requiera un reinicio para implementar los cambios en el código de los rieles, que es lo que está haciendo editando los diseños y las vistas. Parece que realmente está operando en un entorno de desarrollo si está editando el código de la aplicación mientras se está ejecutando. En el modo de producción, no sé de qué forma refrescar Passenger sin tocar restart.txt o reiniciar el servidor web.

EDITAR: Debería poder tocar tmp/restart.txt programáticamente desde dentro de su aplicación. Esto debería indicarle a Passenger que vuelva a cargar en la próxima solicitud.

+0

Definitivamente entiendo que esta no es una aplicación típica de Rails donde los cambios de diseño y vista (junto con cualquier otro código) viven en una el sistema de control de fuente y requiere un reinicio para que las modificaciones surtan efecto. De hecho, el lado de administración funciona así. Esta aplicación solo tiene ese caso de uso especial donde, idealmente, los diseños y las vistas que controlan las páginas públicas podrían cambiarse idealmente sin necesidad de reiniciar el servidor. – cmarin

+0

@cmarin - Esto suena como un caso especial interesante. ¿Puede explicar más detalles sobre por qué necesita este requisito especial? Tal vez nos ayude a encontrar una buena respuesta para usted (es decir, tal vez exista algo que podamos señalarle). – jefflunt

+0

Tal vez las partes de las vistas que cambian a menudo deben ser parte del sistema CMS, lo que les permite ser editadas y almacenadas en la base de datos. – heyrolled

2

José Valim tiene un gran capítulo en "Aplicaciones de Crafting Rails" que trata sobre este tema. Here is an approach que usa Mongoid para almacenar plantillas de vista. Si construye su propio Resolver de vista, solo necesita llamar a #clear_cache en la instancia de resolución cuando alguien guarda una nueva plantilla en la base de datos.

+0

@ monóculo-gracias por ese enlace al capítulo relevante dentro de Aplicaciones de Crafting Rails, voy a echar un vistazo a eso. – cmarin

2

esta configuración puede ayudar (al menos funcionó * para mí):

config.action_view.cache_template_loading = false 
  • obras en los carriles 3

Sólo hay una ligera diferencia en los carriles 2:

config.action_view.cache_template_reloading = false 
+1

'config.action_view.cache_template_loading = false' sigue siendo válido en rieles 4 – Benj

Cuestiones relacionadas