2012-04-06 1 views
18

Я пытаюсь понять, как 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' 

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

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

Aaaaarggggghhhhh!

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

+0

я заметил такое же поведение с https://github.com/grigio/rails_container_and_engines :(но я прилагаю тему двигателя в main_app один с < % = stylesheet_link_tag request.env ["action_dispatch.routes"]. route.routes [0] .defaults [: controller],: media => "all"%> – grigio

ответ

15

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

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

module Enginedemo 
    class DashboardController < ApplicationController 
    end 
end 

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

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

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

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

require 'enginedemo/application_controller' 

module Enginedemo 
    class DashboardController < ApplicationController 
    end 
end 
+18

Или, наоборот, ссылайтесь на правую константу: 'class DashboardController < Enginedemo :: ApplicationController', поэтому вам не нужно явно загружать его всюду. –

+1

Спасибо, у меня была такая же проблема с Rails 4.2.1. Три года спустя ответ по-прежнему очень полезен. – dusan

+0

I he Кроме того, макрос 'require_dependency' также можно использовать вместо требований для этих ситуаций. – Epigene