ruby on rails - rails - Ciclo de vida de aplicaciones de rieles.

ruby on rails tutorial

Question

Estoy tratando de aprender el ciclo de vida de una aplicación de rieles. ¿Cuándo se ejecuta application_controller.rb? ¿Es solo una vez cada vez que se cambia, o en cada solicitud?

Quiero saber lo mismo sobre el siguiente archivo:

• config / environment / *. rb (desarrollo, producción o prueba, dependiendo del modo actual)
• boot.rb
• environment.rb
• rutas.rb

Una de las razones por las que pregunto esto es que quiero saber dónde es un buen lugar para colocar

• código de inicialización
• datos de configuración personalizados

EDITAR:

La respuesta de @Gdeglin es buena, pero estoy realmente interesado en saber cuándo se ejecuta cada uno de estos archivos.

Answer 1

application_controller.rb

ApplicationController es una clase padre para todos los controladores. Los métodos declarados en él estarán disponibles para todos los controladores por este motivo.

ApplicationController es un lugar conveniente para los filtros que desea aplicar a todos los controladores de su aplicación, o los métodos que desea que estén disponibles para todos ellos.

config / environment / *. rb

Los archivos en config / environment / *. Rb anulan la configuración en el archivo config / enviornment.rb predeterminado, según el entorno en el que se ejecuta el servidor (desarrollo / producción). Un ejemplo es que en el desarrollo los errores se imprimen en la pantalla y en la producción se devuelve una página de error genérica. Esta configuración está en config / environment / development.rb

boot.rb

boot.rb se utiliza como parte del proceso de inicialización de rieles. Por lo general, no es necesario, y probablemente no debería tocarlo.

environment.rb

environment.rb es el archivo de configuración genérico para su aplicación.

rutas.rb

route.rb se utiliza para definir cómo su aplicación maneja las solicitudes a direcciones URL específicas. Por ejemplo, es posible que desee que todas las solicitudes 404 vayan a una acción específica en lugar de ser manejadas por el controlador de errores predeterminado:

map.connect ''*path'', :controller => ''home'', :action => ''on_404''

También es una parte importante de la implementación de una aplicación RESTful .

Dónde colocar el código de inicialización y configuración.

Tanto el código de inicialización como los datos de configuración personalizados deben colocarse en enviornment.rb (lea los comentarios en este archivo). Si desea que se ejecute cierto código durante la inicialización solo en el desarrollo o solo en la producción, colóquelo en config / environment / development.rb o config / environment / production.rb respectivamente.

Editar:

Una buena descripción general sobre cuándo se ejecuta cada uno de estos archivos durante la inicialización está disponible aquí:

http://toolmantim.com/articles/environments_and_the_rails_initialisation_process https://github.com/toolmantim/toolmantim/blob/master/articles/environments_and_the_rails_initialisation_process.haml

Esencialmente los pasos son:

1. El Inicializador de Rails está cargado ( http://api.rubyonrails.org/classes/Rails/Initializer.html )

2. El Inicializador de rieles configura el registro y luego carga environment.rb

3. environment.rb carga boot.rb

4. boot.rb establece la constante RAILS_ROOT y agrega bibliotecas de rieles y código de aplicación a LOAD_PATH

5. environment.rb ejecuta Rails::Initializer.run .

6. El marco de los rieles está cargado (ActiveRecord, ActionMailer, etc.)

7. El archivo de configuración específico de su entorno está cargado (config / environment / development.rb.)

8. after_initialize y to_prepare callbacks se ejecutan si ha creado alguna

9. Rails ha terminado de cargarse y está listo para manejar solicitudes

Answer 2

Con un poco de esfuerzo, puedes seguirlo a través de ti mismo, lo que probablemente será más útil.

Comenzar desde ''script / servidor ruby''. En mi aplicación (2.1), busque un archivo llamado "servidor" en el directorio "script". Contiene esto:

#!/usr/bin/env ruby
require File.dirname(__FILE__) + ''/../config/boot''
require ''commands/server''

Por lo tanto, requiere boot.rb, que define un montón de cosas y luego llama a Rails.boot! que más o menos ejecuta cualquier preinicialización que haya definido y luego requiere un environment , lo que hace otro nivel de arranque. Para ese momento ya está empezando a complicarse: recomendaría una hoja grande de papel ...

Y así.

De manera alternativa, puede hackear el Kernel#require para iniciar sesión cuando se Kernel#require un archivo. No lo he intentado (y el método puede anularse en otro lugar) pero podría funcionar ...

application_controller no es exactamente "ejecutable" en absoluto; es una clase primaria para sus otros controladores, por lo que su contenido, si es necesario y no está anulado, estará disponible cuando se cargue el controlador heredado. Por lo general, lo usaría para proporcionar una funcionalidad común en todos sus controladores.

Answer 3

Es una práctica común poner las cosas de inicialización en el directorio config / initializers /. De esta manera usted puede mantener sus archivos environment.rb limpios (er).

Ver este post por Ryan Daigle.

Answer 4

Esto es lo que observé al poner un montón de declaraciones impresas en el código:

El application_controller y el posts_controller (por ejemplo) se "ejecutan" en cada solicitud. Cada línea de código que no está dentro de un método def / end se ejecuta en ambos controladores, y luego el flujo de código pasa al método solicitado / enrutado.

Como esto no es lo que esperaba, pensé que valía la pena publicarlo. Si estoy equivocado por favor siéntase libre de editar.

Con Heroku, la salida de la declaración de impresión solo se muestra en el registro de la salida estándar si la declaración de impresión está dentro de un método, por alguna razón. Pero creo que la descripción anterior sigue siendo válida.