[Moscow.pm] mojo vs catalyst

[Naim Shafiev]

8 июня 2010 г. 15:56 пользователь Yuri Pats <yu.pats на gmail.com> написал:
> Привет, 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 mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>