Делитесь визуальными ресурсами вместе с некоторыми контроллерами между двумя приложениями rails?

Question

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

1. Объединение приложений с пространствами имен и при развертывании есть сценарий, который создает два отдельных пакета RPM (это для развертывания в CentOS / RHEL) ссоответствующие файлы в нем
2. Запустите одно приложение как движок другого.Поместите все общие контроллеры и визуальные ресурсы в приложение верхнего уровня.При развертывании вырвать двигатель, если он мне не нужен.(т.е. если это только первое приложение, и я не хочу давать код второго приложения)
3. Создайте GEM с общими контроллерами и CSS / JS и найдите способ внедрить его в каждоеприложение работает.

Есть мысли / идеи?Я думаю о переходе с номером 1, так как он, вероятно, будет самым простым для разработки (2 будет проще для развертывания, я думаю)

Answer 1

На Яркая планета мы делаем (3). Наш общий макет поддерживает как Rails 2, так и Rails 3.

В частности, вы захотите взглянуть на:

• lib / brighter_planet_layout / rails.rb , который помогает Rails 2
• lib / brighter_planet_layout / railtie.rb , который помогает Rails 3
• lib / brighter_planet_layout / rake_tasks.rb , которая помогает копировать общие файлы в публичные директории Rails 2

Answer 2

Как насчет 4: создать три движка (или драгоценных камня, или движка, инкапсулированных в драгоценные камни): один для общего материала и один для уникального материала каждого приложения?

Answer 3

Рассматривали ли вы создание движка с общими контроллерами, css и js, а затем упаковали его как драгоценный камень. Когда вы работаете локально, вы можете сделать так, чтобы оба приложения указывали на общую копию разработки, используя bundler. Чтобы развернуть, упакуйте драгоценный камень с каждым приложением и разверните все это. Есть много преимуществ сделать его самоцветом, например, возможность иметь разные версии самоцвета в будущем, чтобы вам не приходилось обновлять оба приложения одновременно.

Это похоже на довольно приличное руководство по двигателям: http://www.themodestrubyist.com/2010/03/05/rails-3-plugins---part-2---writing-an-engine/.

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

Answer 4

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

Учитывая, чтоВы хотите взглянуть на различные подходы модульности.На самом деле существует множество опций для обмена кодом:

• gem
• плагин
• библиотечный код, включенный в подмодуль git или эквивалентный
• rails engine
• отдельное развернутое приложение

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

Под «отдельным развернутым приложением» я имею в виду третье приложение, которое имеет общую функциональность.Это могут быть необходимые ресурсы (CSS, JS) и даже части страниц (загружаются динамически).Это потенциально забавное решение, но я видел, что оно работает в правильной ситуации.

И любое из этих решений требует немного больше усилий со стороны разработчиков ... но, в конце концов, лучшепроблемы с развертыванием, которые вы получите, используя mergine *