Жизненный цикл приложений Rails

Question

Я пытаюсь узнать жизненный цикл приложения рельсов. Когда запускается application_controller.rb? Это только один раз каждый раз, когда это изменяется, или на каждый запрос?

Я хочу знать то же самое о следующем файле:

• config / environment / *. Rb (разработка, производство или тестирование, в зависимости от текущего режима)
• boot.rb
• environment.rb
• routes.rb

Одна из причин, по которой я спрашиваю об этом, заключается в том, что я хочу знать, где хорошее место для размещения

• код инициализации
• пользовательские данные конфигурации

EDIT:

@ Ответ Гдеглина хорош, но на самом деле мне интересно знать, когда запускается каждый из этих файлов.

Answer 1

application_controller.rb

ApplicationController является родительским классом для всех контроллеров. По этой причине объявленные в нем методы будут доступны всем контроллерам.

ApplicationController - это удобное место для фильтров, которые вы хотите применить ко всем контроллерам в вашем приложении, или методов, которые вы хотите сделать доступными для всех из них.

конфигурации / среда / *. RB

Файлы в config / средах / *. Rb переопределяют настройки в файле config / enviornment.rb по умолчанию в зависимости от среды, в которой работает ваш сервер (разработка / производство). Одним из примеров является то, что при разработке ошибки выводятся на экран, а при производстве возвращается страница с общей ошибкой. Этот параметр находится в config / environment / development.rb

boot.rb

boot.rb используется как часть процесса инициализации rails. Обычно вам это не нужно, и, скорее всего, не стоит к этому прикасаться.

environment.rb

environment.rb - это общий файл конфигурации для вашего приложения.

routes.rb

rout.rb используется для определения того, как ваше приложение обрабатывает запросы к определенным URL-адресам. Например, вы можете захотеть, чтобы все 404 запроса переходили к определенному действию, а не обрабатывались обработчиком ошибок по умолчанию:

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

Это также важная часть реализации RESTful приложения.

Где разместить код инициализации и конфигурации

И код инициализации, и данные пользовательской конфигурации должны быть помещены в enviornment.rb (см. Комментарии в этом файле). Если вы хотите, чтобы определенный код выполнялся во время инициализации только в разработке или только в производственной среде, поместите его в config / environment / development.rb или config / environment / production.rb соответственно.

Edit:

Хороший обзор того, когда каждый из этих файлов запускается во время инициализации, доступен здесь:

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

По существу, шаги:

1. Загружен инициализатор Rails (http://api.rubyonrails.org/classes/Rails/Initializer.html)

2. Инициализатор rails устанавливает протоколирование, а затем загружает environment.rb

3. environment.rb загружает boot.rb

4. boot.rb устанавливает константу RAILS_ROOT и добавляет библиотеки rails и код приложения в LOAD_PATH

5. environment.rb выполняет Rails::Initializer.run.

6. Загружен каркас рельсов (ActiveRecord, ActionMailer и т. Д.)

7. Загружен специальный файл конфигурации вашей среды (config / environment / development.rb.)

8. after_initialize и to_prepare обратные вызовы выполняются, если вы создали

9. Rails завершил загрузку и готов к обработке запросов

Answer 2

Приложив немного усилий, вы можете следовать за собой через себя, что, вероятно, будет более полезным.

Начните с 'ruby script / server'. В моем (2.1) приложении, которое ищет файл с именем «server» в каталоге «script». Содержит это:

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

Таким образом, он требует boot.rb, который определяет множество вещей, а затем вызывает Rails.boot!, который более или менее выполняет любую предварительную инициализацию, которую вы определили, а затем требует environment, которая выполняет другой уровень начальной загрузки. К тому времени все становится сложнее: я бы порекомендовал большой лист бумаги ...

и т. Д.

Кроме того, вы можете взломать Kernel#require для входа в систему, когда требуется файл - я сам не пробовал (и метод может быть переопределен в другом месте), но он может работать ...

application_controller не совсем "запущен" вообще - это родительский класс для других ваших контроллеров, поэтому его содержимое, если оно требуется и не переопределяется, становится доступным при загрузке наследующего контроллера. Обычно вы используете его для обеспечения общей функциональности всех ваших контроллеров.

Answer 3

Вот что я заметил, поместив в код несколько операторов печати:

application_controller и posts_controller (например) запускаются при каждом запросе. Каждая строка кода, находящаяся вне метода def / end, выполняется на обоих контроллерах, а затем поток кода переходит к запрошенному / маршрутизируемому методу.

Поскольку это не то, что я ожидал, я подумал, что стоит опубликовать это. Если я не прав, пожалуйста, не стесняйтесь редактировать.

В Heroku вывод оператора print отображается только в журнале stdout, если оператор печати по какой-то причине находится внутри метода. Но я верю, что приведенное выше описание по-прежнему применимо.

Answer 4

Обычная практика - помещать материал для инициализации в каталог config / initializer /. Таким образом, вы можете сохранить ваши файлы environment.rb в чистоте (er).

См. этот пост Райан Дейгл.