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

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

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

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

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

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

EDIT:

Ответ на

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

Ответ 1

application_controller.rb

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

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

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

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

boot.rb

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

environment.rb

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

routes.rb

routes.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

По существу, этапы:

Загружается инициализатор Rails (http://api.rubyonrails.org/classes/Rails/Initializer.html)
Инициализатор rails устанавливает регистрацию, а затем загружает environment.rb
environment.rb загружает boot.rb
boot.rb устанавливает константу RAILS_ROOT и добавляет библиотеки rails и код приложения в LOAD_PATH
environment.rb выполняет Rails::Initializer.run.
Загружается платформа rails (ActiveRecord, ActionMailer и т.д.)
Загружается ваш конфигурационный файл, специфичный для вашей среды (config/environment/development.rb.)
after_initialize и to_prepare обратные вызовы выполняются, если вы создали
Rails завершил загрузку и готов обрабатывать запросы

Ответ 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 не совсем "запускается" вообще - это родительский класс для ваших других контроллеров, поэтому его содержимое, если необходимо и не переопределяется, становится доступным, когда загружается контроллер наследования. Обычно вы использовали его для обеспечения общей функциональности всех ваших контроллеров.

Ответ 3

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

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

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

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

Ответ 4

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

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