Rails 3.2 Компоновки движка

Я изо всех сил пытаюсь понять, как Rails 3.2 применяет макеты при использовании монтируемых движков.

Сценарий: я создаю движок, который сам имеет представление панели мониторинга и представление администратора для различных функций администратора. Я хочу, чтобы макет панели управления переопределялся базовым приложением (если пользователь желает), но администратор всегда должен использовать свой собственный макет.

Вот что у меня сейчас внутри двигателя;

application_controller.rb

module Myengine
  class ApplicationController < ActionController::Base

админ / dashboard_controller.rb

module Myengine                                                                                                          
  class Admin::DashboardController < ApplicationController

теперь у меня мои движки application.html.erb применяют ужасный красный фон, в то время как базовые приложения application.html.erb используют приятный желтый фон, чтобы я мог различать, какой макет приложения применяется.

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

Если я перезапускаю сервер и сначала обращаюсь к движку, я вижу красный фон для движка и путь администратора движка, в то время как базовое приложение показывает желтый фон.

Если я изменю свой admin / dashboard_controller.rb следующим образом:

module Myengine
  class Admin::DashboardController < ApplicationController
    layout 'myengine/application'

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

Если я снова перезапущу сервер и получу доступ к корню смонтированного движка, я получу красный фон, который останется на пути администратора движка.

Аааааргггххххх!

Ожидается ли поведение при использовании разных макетов приложения в зависимости от того, к какому пути к приложению обращаются в первую очередь? Неужто нет ?? Я, должно быть, делаю что-то не так!


ruby-on-rails ruby-on-rails-3 rails-engines
person John Beynon    schedule 06.04.2012    source источник
comment
Я заметил такое же поведение с github.com/grigio/rails_container_and_engines :( но я добавляю тему движка в главное_app с ‹% = stylesheet_link_tag request.env [action_dispatch.routes] .routes.routes [0] .defaults [: controller],: media =› all% ›   -  person grigio    schedule 11.04.2012

Ответы (1)


arrow_upward
15
arrow_downward

Я отладил проблему, и на самом деле это не ошибка в движках. Проблема вызвана способом загрузки зависимостей рельсов.

Этот код будет вести себя по-разному в двух показываемых вами сценариях:

module Enginedemo
  class DashboardController < ApplicationController
  end
end

Если ApplicationController уже загружен, rails будет считать, что мы просто хотим его использовать, и вы фактически наследуете не от Enginedemo::ApplicationController, а от ApplicationController. В другом сценарии, когда вы впервые загружаете контроллер движка, ApplicationController еще не загружен, поэтому Rails поступает правильно.

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

Я не уверен, что это можно легко исправить в зависимостях рельсов, я посмотрю на это.

На данный момент, пожалуйста, явно требуйте контроллер приложения:

require 'enginedemo/application_controller'

module Enginedemo
  class DashboardController < ApplicationController
  end
end
person Piotr Sarnacki    schedule 17.04.2012
comment
Или, в качестве альтернативы, укажите правильную константу: class DashboardController < Enginedemo::ApplicationController, чтобы вам не приходилось явно загружать ее везде. - person Ryan Bigg; 18.04.2012
comment
Спасибо, у меня была такая же проблема с Rails 4.2.1. Три года спустя ответ все еще очень полезен. - person dusan; 16.06.2015
comment
Я слышал, что макрос require_dependency также можно использовать вместо require в этих ситуациях. - person Epigene; 18.01.2016