[Moscow.pm] mojo vs catalyst

Yuri Pats yu.pats на gmail.com
Вт Июн 8 04:56:56 PDT 2010


Привет, Catalyst большой и, вообщем-то, ненужный.

Отсутствие документации по mojo с лихвой компенсируется небольшим и
_простым_ code base. Принцип "код лучше всякой документации" в
действии.
По поводу туториалов, рекомендую прочитать примеры использования MVC
для любого языка\фремворка и станет понятно как использовать
каталист/моджо.

Я использую catalyst в качестве диспатчера запросов, + сессии.
Те же базовые потребности удовлетворяет и mojo.

Минусы и catalyst и mojo -- отсутствие на CPAN нормального модуля для
реализации уровня Model.

2010/6/8 Oleg Kostyuk <cub.uanic на gmail.com>:
> Однозначно Catalyst.
>
> Простой, удобный, модульность прям сама просится. Можешь написать как
> угодно, но если "вот так" - то тебе же будет лучше. Я считаю, это одно
> из главных качеств: библиотека прививает стиль её использования.
> Использует Moose, что я тоже считаю за плюс: писать и
> (пере-)использовать роли (они же - roles, traits) для контроллеров и
> моделей - одно удовольствие. Есть несколько готовых "стандартных"
> связок, вроде Cat+DBIC+TT, но и создание новых не проблема. Встроенная
> поддержка app-wide конфигурации. С одного из последних релизов - очень
> простая поддержка добавления своих скриптов, аналогично имеющимся
> ./scripts/myapp_server.pl и им подобных. Много готовых замечательных
> дополнений/расширений, вроде Catalyst-Action-REST,
> Catalyst-Model-Adaptor, Catalyst-Model-DBIC, HTML-FormHandler. Готовое
> решение для написания RESTful сервисов. Готовое решение для DRY -
> chained actions. Великолепная документация.
>
>
> Как состоялся выбор? Да легко. На момент выбора Catalyst был самым
> передовым, прогрессивным и обоснованным решением. По большому счёту,
> на момент выбора было всего две реальных альтернативы - Catalyst и
> CGI::Application. Метался между ними долго, периодически заглядывая в
> документацию соответствующих модулей на CPAN'е. В конце концов бросил
> это дело, и пошёл читать туториалы. От начала и до конца, без
> локального повторения всех описанных действий (дабы не терять нить
> обсуждаемых вещей). Catalyst'овский пример понравился больше. О выборе
> не пожалел ни разу.
>
>
> Вот ссылки для сравнений. Естественно, часть материала устарела, но
> интересующемуся человеку это не помеха - интернет большой, да и Гугл
> пока работает :)
> http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Other
> http://www.cgi-app.org/index.cgi?CatalystCompared
> http://www.wikivs.com/wiki/Catalyst_vs_Ruby_on_Rails
>
>
> Использовать Mojolicious на серьезных проектах считаю неприемлемым, в
> связи отсутствием головы у Себастьяна (основатель проекта, если ничего
> не путаю). На моей памяти ещё ни один cpan-автор не удалял все свои
> творения из-за каких-либо разногласий. Может он и гений, и код
> идеальный - но делать свой проект зависимым от модулей, которые могут
> быть спонтанно удалены bp CPAN'а, я лично не стану. В реальной работе
> это не приемлемо. А "на поиграться" - это можно. И презентации/доклады
> тоже послушаю - расширение кругозора это всегда хорошо.
>
>
> Всё выше сказанное является личным мнением, ответом на вопрос
> топик-стартера, и не в коей мере не предназначено для разжигания войн
> :)
>
>
> --
> Sincerely yours,
> Oleg Kostyuk (CUB-UANIC)
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
WBR, Yuri Pats


Подробная информация о списке рассылки Moscow-pm