2011-07-07 7 views
7

Veo un error/función en mis aplicaciones Ruby 1.9.2. Cualquier cambio a views (no archivos ruby) requiere un reinicio del servidor. Inicialmente me encontré con esto en una aplicación de Rails, pero también he probado lo mismo en una aplicación mínima de Sinatra.Rails 3.1 Not Reloading Changed Views

voy a incluir una aplicación sencilla para demostrar

# testapp.rb 
require 'sinatra' 

get '/' do 
    [0,1,2].to_s #change this to [0,1].to_s 
end 

Ésta es mi procedimiento:

  • ruby testapp.rb (corre servidor delgado para mí)
  • carga de la página
  • abrir el archivar y editar la vista
  • volver a cargar la página (no veo cambios)
  • matar el servidor
  • reiniciar el servidor (cambios ahora visibles)

He estado en desarrollo en Ruby on Rails 1.8.7 3 durante los últimos meses. Tener que reiniciar el servidor en cualquier cambio de vista ralentiza el desarrollo severamente.

He listo this SO thread, pero en mi versión de Rails (3.1.0 rc4), la variable de configuración ya está configurada según esa respuesta. Además, puedo replicar el error usando Sinatra, por lo que no parece ser el caso.

¿Alguien puede arrojar luz sobre este tema?

Rubí versión: rubí 1.9.2p180 (2011-02-18 revisión 30909) [x86_64-linux] Servidor: delgada 1.2.11 (también probado esto con Sinatra/WEBrick)

EDITAR 7/13 , Aclaración La cuestión de Sinatra es un problema aparte: la recarga de la fuente de Sinatra está deshabilitada de forma predeterminada. He utilizado este código para probar el comportamiento:

require 'sinatra' 
require 'sinatra/reloader' 
require 'haml' 

set :views, 'views' 

get '/' do 
end 

get '/test' do 
    haml :test 
end 

Con esto, hice un archivo: views/test.haml. Modificándolo mientras el servidor se está ejecutando muestra un cambio cuando la página se vuelve a cargar. Gracias a Tiredpixel por señalar esto

cuestión no resuelta: ¿por qué los carriles 3.1 de Ruby no 1.9.2 recargar la vistas? Puedo obtener archivos ruby ​​para cargar, pero no archivos haml y erb. Termino reiniciando el servidor solo para ver si un error fue reparado (o no) debido a que un archivo no se carga correctamente.

EDITAR/SOLUCIÓN (copiada de mi comentario en la respuesta aceptada):

El problema estaba en config/environments/development.rb

config.cache_classes = false 

Incluso después de haber dejado esto era correcto, que todavía tenía el problema.Más abajo, en el archivo que teníamos:

config.threadsafe! 

Lo que esto hace es establecer las 3 banderas siguientes true: config.allow_concurrency, config.preload_frameworks, y (¡sorpresa!) config.cache_classes.

Para corregir: mueva config.threadsafe! arriba de config.cache_classes, para que no quede anulado implícitamente.

+1

Acabo de crear una aplicación nueva de 3.1.0 rc4 y [la he enviado a github] (https://github.com/ezkl/reload_test). Tiene un controlador con un solo método y una ruta. Estoy ejecutando 1.9.2-p180. Cuando ejecuto 'thin start', navego' http: // localhost: 3000/', realizo cambios en' app/views/pages/index.html.erb', las vistas se vuelven a cargar correctamente. –

+1

Gracias por empujar esto. Aparentemente era un problema con 'config.threadsafe!' Escribiendo sobre 'config.cache_classes' –

Respuesta

7

Rails normalmente está configurado para recargar automáticamente en cada solicitud, mientras se encuentra en el entorno de desarrollo. Sin embargo, esto no ocurre con los archivos en lib/.

La experiencia que describe con Sinatra está destinada (la recarga automática se eliminó en 0.9.2): http://www.sinatrarb.com/faq.html#reloading; la gema Shotgun se puede instalar para realizar esta recarga.

+0

Hm, supongo que mi publicación apuntaba a 2 problemas diferentes y no me di cuenta. Voy a actualizar que –

+3

Ha comprobado 'config/ambientes/development.rb' ' config.cache_classes = false' y 'config.action_controller.perform_caching = false' ? – tiredpixel

+2

Así que esto estaba yendo por el camino correcto. Alguien en mi equipo lo consiguió. Ya teníamos 'config.cache_classes = false' (así como la otra bandera que mencionaste). Sin embargo, más abajo en el archivo teníamos: 'config.threadsafe!'. Lo que hace esto es establecer los siguientes 3 indicadores en verdadero: 'config.allow_concurrency',' config.preload_frameworks', 'config.cache_classes'. La solución, entonces, era mover 'config.threadsafe!' A las anteriores 'config.cache_classes', para que no se invalide implícitamente. –