Несколько воплощений одного приложения Rails - PullRequest
1 голос
/ 19 ноября 2010

Каков наилучший способ организации нескольких, слегка измененных воплощений в одном приложении Rails?

Воплощения различаются в зависимости от css, изображений, базы данных и домена.Приложение / логика в остальном точно так же.Существует вероятность того, что публичные имена путей некоторых маршрутов должны будут различаться, но все же структура маршрутов будет одинаковой.

Поэтому я подумываю о единой установке приложения и управлении этими изменениями в среде.

БД, очевидно, уже настроена для этого.Я думаю, что CSS и пути к изображениям было бы достаточно легко сделать окружающими.Маршруты не должны быть слишком сложными, я думаю, в любом случае, теоретически.

Причина, по которой я пишу этот пост, заключается в том, что я уверен, что эта проблема должна быть решена.Есть ли существующий камень "скины" или что-то, что я могу использовать для этого?В противном случае, любые комментарии по моему запланированному подходу будут с благодарностью!Я использую Rails 3.

Ответы [ 2 ]

1 голос
/ 19 ноября 2010

Многое зависит от того, почему вы пытаетесь достичь этого. В настоящее время мы обслуживаем четыре разных «приложения» на нескольких разных доменах и поддоменах из одного и того же Rails-приложения. Мы делаем это потому, что у нас есть разные клиенты, которые хотят видеть разные особенности нашего продукта. Например, каждый продукт разделяет идею клиентов, контрактов, продавцов и многих других моделей, но они хотят, чтобы сайт назывался по-разному, названия вкладок и пунктов меню назывались по-разному, а некоторые части сайта были недоступны для определенных людей.

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

Для простоты я назову кожу, которая в нашем случае является отдельным продуктом.

В нашем приложении есть плагин, который настраивает некоторые переменные среды на основе входящего домена. Затем, основываясь на этих переменных, наше Rails-приложение будет в зависимости от обстоятельств использовать различные макеты и партиалы Эти макеты затем ссылаются на соответствующие JS и изображения, которые хранятся в местах, которые имеют смысл для дизайнеров и разработчиков внешнего интерфейса. Например, customer.js может хранить обычные операции клиента, тогда в подкаталоге может быть файл customer.js для темы оформления, который расширит основной файл customer.js (для этого мы используем Dojo).

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

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

Для CSS мы используем SASS, поэтому большую часть времени вы можете использовать миксины для цветов и изображений. Мы делаем это, имея корневой файл SASS с информацией макета, которая использует переменные для цветов и изображений. Затем нам потребуются эти цветные файлы и файлы изображений в корневой SASS по мере необходимости.

Ответ может быть лучше, если вы дадите некоторую информацию о том, как вы определяете между этими двумя скинами. Насколько я знаю, уже есть плагины доменов, которые могут помочь вам определить, к какому сайту пытается обратиться пользователь. Что касается того, как организовать ваше приложение для отображения правильного CSS, изображений, JS и т. Д., Надеюсь, то, что я обрисовал в общих чертах, немного поможет.

1 голос
/ 19 ноября 2010

Почему бы просто не поддерживать отдельные ветки в вашей системе контроля версий?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...