CMS on Rails: много вопросов, нужно ваше мнение
zoz...@gmail.com
В компании, где я работаю, приняли решение (наконец!), что текущая CMS
устарела и дальнейшее её сопровождения - тупик. Не удивительно - она
ещё на ASP (не .NET) была написана.
Начав чуть больше полу года назад работать с Ruby on Rails (над своим
проектом snowdb.com), я активно пропагандировал использование этой
технологии для дальнейших разработок. В общем, принято решение,
разрабатывать новую CMS на Ruby on Rails. Собственно, этим я и буду в
ближайшем будущем заниматся.
А пока у меня есть некоторое кол-во вопросов, как лучше реализовать
некоторые принципиальные моменты.
Наверное, все сайты, которые будут работать на этой CMS, можно
разделить на две части: стандартная функциональность и <<расширенная>>,
которая будет разрабатыватся под конкретный проект. При этом,
очевидно, есть желание регулярно обновлять во всех проектах <<основную>>
часть, как только в ней появилось что-то новое, или исправилось
старое.
Первое, что приходит в голову - оформить <<основную>> часть, как плагин
и ставить его во все проекты. Пока что мне не приходилось самому
писать плагинов и глубоко в этот вопрос я не влезал. Однако, насколько
я знаю, не всё можно вынести в плагин. Напрмер модель - нельзя. Помимо
этого, <<основная часть>> будет содержать не мало таких вещей, как
достаточно массивные JS-файлы (бэкофис будет на ExtJS) и другие
статический файлы. Их выносить в плагины тоже, насколько я понимаю,
даже если и возможно, то неудобно?
Была масль оформить это всё в виде плагина, который с помощью
различных генераторов ставит в проект все необходимые файлы и
расширения. Но как тогда следить за версионностью и изменениями,
которые были сделаны от отной до другой версии <<основной>> части?
Как поступить с разработкой плагина? Насколько я понимаю, разработка
кода плагина гораздо менее удобна, чем кода основного приложения? Там
не всегда (если вообще) работает отладка и не весь код обновляется
сразу (без перезапуска приложения) даже в development environment?
Я понимаю, что мне не удалось сформулировать четкие вопросы, на
которые вы мне можете ответить, однако мне было бы очень интересно
услышать ваши, прифессиональные и более опытные советы и рассуждения
на эту тему. Как лучше решить мою задачу?
Я сильно впечатлен красотой и изяществом всего мира ruby и очень не
хочу, что бы мне снова пришлось завязываться на некрасивые и
неприятные (как минимум, лично мне) технологии типа .NET, PHP...
Большое спасибо!
leonid bugaev
Added app/[models|controllers|helpers] to the load path for plugins that has an app directory (go engines ;)) [DHH]
Генератор не надо, с этим функционалом станет намного проще такой подход использовать.
Dmitri Lifshits
С помощью вышей ссылки нашел http://rails-engines.org/ - изучаю...
28 января 2009 г. 15:25 пользователь leonid bugaev <leon...@gmail.com> написал:
leonid bugaev
Maxim Alex. Pechnikov
Вот хорошее описание как это делать.
http://www.html-blog.ru/2008/10/1/git-project-support
спасибо Декарту.
On 28 янв, 17:38, Dmitri Lifshits <zoz...@gmail.com> wrote:
> Спасибо!
>
> С помощью вышей ссылки нашелhttp://rails-engines.org/- изучаю...
>
> 28 января 2009 г. 15:25 пользователь leonid bugaev <leons...@gmail.com> написал:
>
> > Added app/[models|controllers|helpers] to the load path for plugins that has
> > an app directory (go engines ;)) [DHH]
>
> >http://github.com/rails/rails/commit/63d8f56774dcb1ea601928c3eb6c119d...
Dmitri Lifshits
Предполаю, что этот engine - некий плагин, который позволяет делать
то, что сейчас добавили в EDGE?
В любом случае, почитаю, для поиска интересных идей.
Спасибо за предупреждение!
28 января 2009 г. 15:42 пользователь leonid bugaev <leon...@gmail.com> написал:
Dmitri Lifshits
противится против отказа от привычного SVNа, буду на этом настаивать.
Спасибо - почитаю.
28 января 2009 г. 15:43 пользователь Maxim Alex. Pechnikov
<paral...@gmail.com> написал:
Marat Karimov
и по пользователям
http://github.com/tog
http://github.com/suratpyari
http://github.commolpe
http://github.commjuneja
основное предназначение социальные сети но очень хорошо организована
система плагинов - можете либо использовать либо взять на заметку
организацию
2009/1/28 zoz...@gmail.com <zoz...@gmail.com>:
Julik Tarkhanov
Была масль оформить это всё в виде плагина, который с помощью
различных генераторов ставит в проект все необходимые файлы и
расширения. Но как тогда следить за версионностью и изменениями,
которые были сделаны от отной до другой версии <<основной>> части?
Как поступить с разработкой плагина? Насколько я понимаю, разработка
кода плагина гораздо менее удобна, чем кода основного приложения? Там
не всегда (если вообще) работает отладка и не весь код обновляется
сразу (без перезапуска приложения) даже в development environment?
Я понимаю, что мне не удалось сформулировать четкие вопросы, на
которые вы мне можете ответить, однако мне было бы очень интересно
услышать ваши, прифессиональные и более опытные советы и рассуждения
на эту тему. Как лучше решить мою задачу?
Помимо
этого, <<основная часть>> будет содержать не мало таких вещей, как
достаточно массивные JS-файлы (бэкофис будет на ExtJS) и другие
статический файлы. Их выносить в плагины тоже, насколько я понимаю,
даже если и возможно, то неудобно?
Max Lapshin
Julik Tarkhanov
напрягусь на 10 минут починить гем и
выкатить его по новой, чем запатчу что-
то левой ногой в svn trunk а потом выясню
что еще три аппы сломались из-за этих
изменений на ближайшем cap deploy. Это next step
после svn externals просто :-) и возникает он
когда externals создают аццкий бардак
--
Julik Tarkhanov
m...@julik.nl
Oleganza
то можно зацепляться за номер коммита
или тег, что гораздо проще, чем
редеплой гема. А аккуратность та же.
Julik Tarkhanov
> А аккуратность та же.
Вопрос вкуса. На мой взгляд гем нам
роднее чем гит.
--
Julik Tarkhanov
m...@julik.nl
Oleganza
On 28 janv. 09, at 23:58, Julik Tarkhanov wrote:
> Вопрос вкуса. На мой взгляд гем нам
> роднее чем гит.
гиморнее. Поэтому я и думал о гит-гемах,
когда можно заказать что-то вроде:
gem "blah-blah", "=abf46fae6742b78fe8ee9b8e6742b78f9b3"
а сами гемы - вычекнуты из гит-
репозиториев. Идея прикольная, но я
пока не уверен до конца в
необходимости такой фичи.
Oleg...@gmail.com
> а сами гемы - вычекнуты из гит-
> репозиториев. Идея прикольная, но я
> пока не уверен до конца в
> необходимости такой фичи.
А, вот только что увидел во френдленте гитхаба:
http://github.com/mislav/coral/tree/master
Проекту два дня от силы.
Val
оснве гем-серверов, все компоненты были ввиде гемов (включае само
рельсовое приложение), и когда приложение было готово к QA, скрипт
собирал все версии гемов, забрасывал их на QA гем-сервер. Когда QA
давал добро, то же скрипт промоутил с QA в prod.
On Jan 28, 5:04 pm, Julik Tarkhanov <julian.tarkha...@gmail.com>
wrote:
Max Lapshin
А это разница в стратегии. Я лучше
напрягусь на 10 минут починить гем и
выкатить его по новой, чем запатчу что-
то левой ногой в svn trunk а потом выясню
что еще три аппы сломались из-за этих
изменений на ближайшем cap deploy. Это next step
после svn externals просто :-) и возникает он
когда externals создают аццкий бардак
Как верно сказали, не пользуйся subversion-ом =), а во-вторых, речь идет не о 10 минутах.
Речь идет о реализации какой-то новой функциональности, которую приходится править и девелопить.
Dmitri Lifshits
> Это не решает проблем типа установки плагиновских рейк-тасков, но на первое
> время этого хватает (ты получаешь встроенное управление
> зависимостями от rubygems).
Как и многим тут, мне тоже на первый взгляд больше нравится идея с
GIT'ом, т.к. это позволяет при разработке одного из приложений,
использующего что-то базовое, сразу вылить какие-то изменения в это
базовое. Ну и так же это это более динамично, что ли. Не надо собирать
гемы, обновлять.
> Тану. Все там обновляется, а перезапуск тебе не нужен потому что как правило
> плагин делается вслепую, test driven. Пример хелпера чтобы тестить плагин:
> http://github.com/julik/make_like_a_tree/blob/658119c0004bb9dfef43acef7754c557e9cd4c5a/test/test_ordered_tree.rb
> Первые 30 строк бутстрапят тебе все что нужно чтобы гонять в изолированной
> ситуации ActiveRecord с определенной базой.
TTD это одно, а быстрый подхват изменений и дебаг, это другое. Только
что проверил - дебаг работает, изменения без рестарта не
подхватываются (Ubuntu 8.10, NetBeans), так что это проблема.
Насколько я понимаю, эти 30 строк кода создают тестовые данные, что бы
прогнать по нима тесты? Чем мне это поможет?
> Взять готовый велосипед, видимо.
> rubyconf2008.confreaks.com/components-are-not-a-dirty-word.html
> http://apotomo.de/
> http://wiki.github.com/fesplugas/typus
Сел за изучение, спасибо!
> Ну или там desert, engines.
> Но там где рельсовики слышат слова "CMS" и "component" все как правило
> закрываются веерами и говорят "дурно мне дурно",
> хотя на самом деле надо то всем и часто. Это посконное но реальное.
Ну вот про engines Леонид мне выше советовал не связыватся с ними...
> Ты с этим делом аккуратнее, за extjs ващето платить надо - и немалые деньги.
Эм... Насколько я понимаю, до 289$ за разработчика?
(http://extjs.com/store/extjs/)
Так что, не вижу больших проблем.
> Выносить не очень удобно поскольку это надо делать статикой - а ее надо
> выплевывать в рут как никак.
> Можно из плагина вывесить в руты свой контроллер assets который после
> первого хита выплевывает в public
> нужные детальки нужной версии.
Примерно ясно, но хотелось бы что-то покрасивее :(
> По поводу управления своей системой библиотек гемами есть на confreaks
> какая-то презентация, но в общем и целом
> это совершенно несложно.
> P.S. знаю что меня закидают гнилой капустой - но у 90 процентов
> админо-цмсно-компонетных проектов чудовищный
> английский в документации и readme, и большинство разработчиков из _стран_.
> Что наталкивает на мысль что в стандартной
> рельсовой экосистеме (сильно американизированной) таки закрываются веером,
> потому что на конкретную задачу конкретное
> приложение. И поделом - гнусное это дело, цмски для всего. Паганое. Нужно
> как правило либо ненавидимому суперэнтерпрайзу
> либо не менее ненавидимой "миграции с пыхыпы".
В общем-то, да. И в нашем случае это примерно и то и то. Только не
супер и было ASP вместо PHP. Но бизнес никто менять не будет из-за
того, что Rails-сообществу не нравится то, для чего используют их
творение. Согласен, что это не самое "благородное" использование, но
такова задача.
И мне бы хотелось её решать именно на ruby.
Большое спасибо за ваш ответ!
leonid bugaev
Sergei
> и ставить его во все проекты. Пока что мне не приходилось самому
> писать плагинов и глубоко в этот вопрос я не влезал. Однако, насколько
> я знаю, не всё можно вынести в плагин. Напрмер модель - нельзя. Помимо
> этого, <<основная часть>> будет содержать не мало таких вещей, как
> достаточно массивные JS-файлы (бэкофис будет на ExtJS) и другие
> статический файлы. Их выносить в плагины тоже, насколько я понимаю,
> даже если и возможно, то неудобно?
С текущей версией рельс в плагин можно добавлять не только модели, но
и контроллеры, и даже маршруты. Я этим активно пользуюсь в своих
плагинах/гемах, и даже выдаю CSS и JavaScript прямо изнутри плагина
(т.е. не используя генераторы, что, конечно, очень здорово). Хорошо
все расписано на официальной странице рельс: http://guides.rubyonrails.org/creating_plugins.html
(не знаю, переведено ли это где-то на русский).
Что касается бэкэнда, рекомендую взглянуть на Netzke, мой
развивающийся фреймворк, предназначенный прежде всего как-раз для
этого: бэкэнды на Rails+ExtJS. Живое демо здесь: http://netzke-demo.writelesscode.com/
Удачи!