Rails 3.1. Пользовательские контроллеры и представления с / по умолчанию

Question

Справочная информация:

• Я создаю приложение, которое позволяет пользователям создавать свои собственные веб-сайты (например, mywebsite.alexlod.com)
• Каждый владелец веб-сайта связан со мной,поэтому я доверяю им писать свой собственный код rails
• Каждый веб-сайт должен иметь контроллеры и представления по умолчанию, кроме случаев, когда один из этих владельцев создает свои собственные

Вот как я представляю контроллерыработает:

Я думаю, что то, что в app/controllers/ будет по умолчанию, но когда файл указан в каталоге <subdomain> верхнего уровня, этот файл будет иметь приоритет над значением по умолчанию.

Позвольте мне привести пример.Допустим, один из владельцев моего сайта (foo.alexlod.com) хочет настроить app/controllers/photos_controller.rb.Они должны быть в состоянии создать foo/controllers/photos_controller.rb, при этом вместо контроллера по умолчанию используется их контроллер.Я думаю, что правильный подход здесь как-то связан с маршрутами и путем загрузки, но я новичок в Rails и Ruby и могу использовать некоторые рекомендации.

Что касается представлений, я бы хотел, чтобы они работалипочти такой же.Когда представление или частичное задано в <subdomain>/views/, это представление используется вместо значения по умолчанию, расположенного в app/views/.

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

Answer 1

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

Вот что я сделал для просмотров:

в app / controllers / application_controller.rb

before_filter :prepend_view_path_if_subdomain

def prepend_view_path_if_subdomain
  unless pSubdomains.blank?
    subdomain = request.subdomain.first

    #This will add the subdomain view directory to the view path before the default
    #Rails view directory and any views here will be picked up and rendered.
    prepend_view_path 'app/' + subdomain + '/views'
  end
end

Делать то же самое для контроллеров, однако, немного сложнее из-за маршрутизации. Не существует метода prepend_controller_path, который эквивалентен prepend_view_path. Честно говоря, я не уверен, как подойти к этому, вы могли бы использовать подход с помощью case case или, возможно, динамически пересылать запрос к контроллеру поддоменов (если он существует). Я думаю, что возможно было бы добавить before_filter к вашим контроллерам, который оценивает каждый запрос так же, как я показываю выше с представлениями, а затем определяет, какой контроллер следует использовать.

Я также наткнулся на этот вопрос: Rails 3.1 загружает контроллер с другого пути, основанного на поддомене , не уверен, поможет ли он вам или нет.

Answer 2

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

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

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