Контекст проблемы - это форма мультитенантного приложения. Различные объекты имеют доступ к центральному набору классов и методов. Однако представления могут быть полностью перенастроены с помощью центрального метода. Кроме того, некоторые специальные c методы могут быть разработаны для данного объекта, который мы будем называть @site.
Таким образом,
class SharedmethodsController < ApplicationController
class SitexController < SharedmethodsController
, где Sitex включает уникальное имя сайта
Представления будут номинально размещаться в подкаталоге sites/sitex
Таким образом, хотя руководство по маршрутизации рельсов обеспечивает механизм доступа к хорошо идентифицированному маршруту из нескольких объекты
resources :magazines do
resources :ads
end
это только обеспечивает привязку к id объектам.
Первая проблема в том, что у нас нет ни определения имени контроллера, ни четкое представление о том, где сохранить контроллер и представления в соответствии с соглашением о рельсах. Этот символ относится к классу stati c, таким образом, это означает, что для каждого нового сайта должен быть объявлен новый набор ресурсов.
Вторая проблема - как лучше настроить представления. Представления Sitex в большинстве случаев будут такими же, как и унаследованные методы Shared. Альтернативой может быть создание символических ссылок при создании сайта. По умолчанию использовать Rails logi c может быть проще, так как это выглядело бы в папке sitex, sharedmethods и views; потенциальные конфликты имен, тем не менее, не за горами. c, чтобы учесть любой новый случай в этом сценарии?