наиболее подходящая форма, чтобы сделать повторно используемый код Ruby on Rails более повторно

Question

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

Среди вещей, которые я повторно использую, следующие:

CSS-файлы, инициализаторы, просмотры / общие / частичные изображения администратора помощники приложений шаблоны просмотра хамла драгоценные камни и т.д ...

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

Какие рекомендуемые способы сохранить весь этот «персональный» код более или менее модульным, чтобы я мог «добавить» его в новый проект rails и отредактировать как обычный код rails (без компиляции / публикации гемов).

Два слова, которые приходят на ум, - это движки и плагины, но я действительно мало знаю о том, как работает любое из них. Я также слышал о (смущающем) «шаблонах», а не о виде представления.

Каковы ваши предложения. Я хотел бы выяснить это!

Answer 1

Вы находитесь на правильном пути с шаблонами + движками.

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

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

rails plugin new pixelearth_base --mountable

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

Позвольте мне показать вам пути.

CSS файлы / изображения

CSS-файлы попадают в app/assets, как в приложении Rails 3.1, и затем обрабатываются таким же образом. Подробнее о них вы можете прочитать в руководстве Asset Pipeline . Вы можете ссылаться на них точно так же, как если бы они были в вашем приложении. Разумеется, любой ресурс в вашем приложении, названный идентично тому, который находится внутри вашего движка, будет иметь приоритет.

Инициализаторы

Они идут в config/initializers, как приложение (подсказка: это запущенная тема с движками). Они работают одинаково и объясняются в этом разделе Руководства по настройке , хотя, я полагаю, вы уже много знаете об этом.

Общие виды

Они входят в app/views/shared в вашем двигателе. Любой файл в вашем приложении с одинаковым именем будет иметь приоритет над файлом в движке. Приложение сможет беспрепятственно получать доступ к любому файлу в этом каталоге, так как к движкам добавлены пути их просмотра.

Partials

Ditto.

Администратор

Вы пробовали замечательный rails_admin движок для этого? Возможно, это подойдет вам. Если нет, вы можете встроить эту функциональность в свой движок так же, как в приложении.

Помощники

Работают во многом так же, как и все остальное. Добавьте их в свой двигатель, и вам будет хорошо. Хотя я не уверен в этом последнем пункте, вам, возможно, придется сделать helper SomeHelper в верхней части контроллера, чтобы включить их.

Haml

Укажите это как зависимость двигателя в файле pixelearth_base.gemspec двигателя, используя следующую строку:

s.add_dependency 'haml', '3.1.3'

Ваш движок (и, соответственно, ваше приложение) сможет использовать haml в представлениях.

Шаблоны

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

Драгоценные камни

Как и в примере с хамлом, в pixelearth_base.gemspec должны быть указаны общие гем-зависимости.

---

Включая двигатель

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

вашего приложения.

gem 'pixelearth_base', :git => "git://github.com/pixelearth/pixelearth_base"

Каждый раз, когда вы обновляете этот гем и вносите новые изменения в GitHub, вам нужно будет запустить bundle update pixelearth_base, чтобы обновить приложение до последней версии. Каждый раз, когда вы запускаете bundle update, он будет привязан к этой конкретной версии. Любые дальнейшие изменения в двигателе не будут подтверждены, пока вы снова не запустите bundle update ....

---

Подвеска двигателя

Последнее, о чем вы спрашивали в IRC, - это монтирование. Если вам случится пойти по пути совместного использования функциональности в вашем движке (то есть контроллерах и т. Д.), Вам нужно будет смонтировать ваш движок в вашем приложении. Это очень просто и может быть сделано, поместив эту строку в ваш config/routes.rb:

mount PixelEarth::Engine, :at => "pixelearth"

Класс PixelEarth::Engine определен в вашем движке на lib/pixel_earth/engine.rb и предоставляет все необходимые функциональные возможности, наследуя от Rails::Engine. Любая функциональность из вашего приложения теперь будет доступна на /pixelearth в вашем приложении.

Answer 2

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

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

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

Однако вы не можете просто написать хороший код и оставить все как есть, у вас должен быть хороший способ распространения вашего кода. В моей локальной сети есть сервер разработки, на котором размещено много частных Git-репозиториев, однако вы можете использовать любую VCS или DVCS для организации своего кода. Затем я могу использовать это для того, чтобы мои проекты получали последние версии файлов с сервера, когда мне нужно обновить их и внести изменения, и я всегда могу перейти, если мои требования изменятся для проекта, над которым я работаю. С Git у меня всегда есть мой код в управлении версиями, поэтому я использую субмодули , чтобы позволить мне держать последнюю версию кода под рукой и в курсе.

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

Answer 3

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

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