[Moscow.pm] В чем смысл Catalyst?

Yuri Pac yu.pats на gmail.com
Пн Ноя 17 00:33:14 PST 2008 

2008/11/17 Анатолий Шарифулин <sharifulin на gmail.com>:
> Дима, ты хочешь сказать, если я не использую "веб фреймворки, такие как
> Catalyst", то я не в состояние придумать "хорошую концепцию" для поддержки
> "больших громоздких продуктов", которые имеют тенденицию расти?
>
> По-моему, веб-фреймворки стоит использовать тогда, когда у вас нет сил или
> желаний покреативить, заняться тренингом мозгов. Ведь что может быть лучше
> практики -- только сама практика :) Можно следить за фреймворками, чтобы
> быть в курсе новых идей, подходов и технологий. Но есть другая сторона
> медали -- осознание того, что ты движешься против течения (майн-стрима) :)
>
Если у вас есть группа разработчиков для поддержки фреймворка, то это супер.
И стоит его развивать и в последствии расшарить на цпан :)

Когда вам нужно приложить минимум усилий для написания рутины, и
больше для адаптации legacy-базы, то тут уж лучше идти протоптанной
дорогой.
>
> 16 ноября 2008 г. 22:35 пользователь Dmitry Simonov <dsimonov на gmail.com>
> написал:
>>
>> Привет!
>>
>> В традиционных мануалах по перлу разумеется все примеру показываются с
>> использованием CGI-скриптов, где всё записано вместе –sql-запросы, куски
>> html-кода и даже нередко java-script-вставки. И кое-где в промежутках между
>> этим всем добром иногда встречается перл :)
>>
>> Начинающие разработчики с этого и начинают.
>>
>> Тот, кто понимает HTTP-протокол и SQL, вероятно, будет в состоянии понять
>> большую часть этого кода, потому что в нем используются стандартные техники
>> веб-разработки. Кодирование этим способом предоставляет разработчику
>> огромное количество возможностей, так как разработчики обладают контролем
>> над каждым видом HTTP-ответа и могут писать настолько сложные SQL-запросы,
>> насколько захотят.
>>
>> Такой скрипт разумеется проще написать, чем большой громоздкий продукт, а
>> уж собрать из нескольких скриптов некий сайт вообще задача вполне решаемая.
>>
>> Эти скрипты, собранные в сайт, будучи однажды отлаженными, работают
>> годами. Дёшево и сердито. Я слышал про команды под руководством известных
>> здесь на листе рассылке деятелей, которые в общем всю работу на таких
>> скриптах и строят. Так как оптимизировать и развивать сами эти скрипты
>> довольно сложно, то новую функциональность получают  либо рисуя на коленке
>> новый скрипт и путём шаманских действий, включая их в общем комплект, либо
>> вообще тупо копируют один из существующих скриптов для добавления скажем
>> нового раздела на сайте.
>>
>> Решение дешёвое и сердитое.  Это отлично работает с простыми или даже
>> небольшими, но нетривиальными приложениями, но все программные продукты
>> имеют тенденцию расти, и без хороших концепций, они становятся проблемными в
>> обслуживании и поддержке. То есть перестают быть сначала простыми, а потом
>> дешёвыми.
>>
>> Это действительно ОЧЕНЬ трудоёмко – развивать такие скрипты, в которых
>> намешано всё. Трудности начинаются с того, что каждый скрипт на сайте
>> нуждается в аналогичном коде, чтобы загружать конфигурационный файл и
>> обрабатывать ошибки. Написание кода доступа к базе данных очень часто
>> повторяется, а структуры данных из базы не обязательно представляют объекты,
>> с которыми Ваше приложение захочет иметь дело. Дизайнерам покажется сложной
>> смена темы сайта, так как код, генерирующий HTML, перемежается с кодом Perl.
>> И наконец CGI-скрипты могут быть медленными, потому что весь интерпретатор
>> Perl в целом, как и модули, используемые скриптом, требуют загрузки в память
>> на каждом запросе.
>>
>> Давайте ещё раз подробнее посмотрим, из чего эти скрипты состоят
>> функционально:
>>
>>     * нечто, что генерирует HTML;
>>     * нечто, что разбирает аргументы, переданные по HTTP;
>>     * нечто общающееся с базой данных;
>>     * нечто содержащее логику вашего приложения;
>>     * нечто управляющее пользовательскими аккаунтами;
>>     * нечто сохраняющее промежуточные данные (напр. сессии, основанные на
>> куках).
>>
Каталист в себе имеет:
>>     * нечто, что разбирает аргументы, переданные по HTTP;
>>     * нечто сохраняющее промежуточные данные (напр. сессии, основанные на
>> куках).
остальное все плагины, плагины, плагины...

>> Если вы писали веб приложение (даже если это был простейший скрипт,
>> выводящий "Hello, World!"), то значит вы писали бОльшую часть вещей,
>> описанных выше, самостоятельно. Вы, возможно, просто использовали print для
>> создания HTML и не заботились о сложных системах шаблонов. Иными словами,
>> через некоторое время у вас будет куча программ, которые выводят HTML
>> подобным образом. Уверен, вы можете перенести некоторые общие части в модули
>> и использовать их из всех ваших программ. Но в действительности, вы ищите
>> решения для сверхтипичных задач, возникающих в каждом веб приложении.
>>
>> Так что некоторые продвинутые люди потратили свое свободное время для
>> создания компонент, которые "закрывают" эти ежедневные задачи. Например,
>> существуют Perl пакеты Mason, который работает с созданием HTML — т.е.
>> является системой шаблонов. Используя TT, вы создаете файл (называемый
>> шаблоном), который содержит целиком вашу HTML страницу. У вас есть
>> возможность добавить Perl конструкции прямо в этом файле, в том месте, где
>> вам нужно, а также получить доступ к переменным из других частей вашего
>> приложения. И поскольку эти шаблоны могут использовать друг-друга, то вы
>> имеете возможность легко поменять дизайн вашего сайта, просто изменив
>> базовый шаблон.
>>
>> Это просто пример того, как компоненты могут облегчить жизнь программисту.
>> И существует большое количество уже готовых компонент. Это очень хорошая
>> идея — использовать их, вместо того чтобы вручную разбирать каждодневную
>> рутину. А теперь представьте, что у вас несколько полезных компонент и они
>> работают слаженно, вместе.
>>
>> Так вот, веб фреймворки, такие как Catalyst, как раз и занимаются этим.
>>
>> P.S. для написания данного ответа использовалось несколько статей на
>> сходную тематику и если кто-то увидит здесь знакомые строчки, просто
>> поразитесь насколько затронут типовой вопрос и как легко он ложится на
>> современные perl-технологии :)
>>
>>
>> 2008/11/14 Dmitry E. Oboukhov <unera на debian.org>
>>>
>>> нет я не менеджер :)
>>> но как-то просмотренные примеры не убедили
>>> на схожие действия схожее количество кода ну и засомневался
>>> я а стоит ли оно того?
>>>
>>> --
>>> ... mpd is off
>>>
>>> . ''`.                               Dmitry E. Oboukhov
>>> : :'  :   email: unera на debian.org jabber://UNera@uvw.ru
>>> `. `~'              GPGKey: 1024D / F8E26537 2006-11-21
>>>  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>
>>> iEYEARECAAYFAkkd4ZYACgkQq4wAz/jiZTeYqACgndHA/MwuvyNJkaiuwP8VHIHx
>>> ixwAnjexN4bZuva16S61R2qzE9J77uLq
>>> =Y8IH
>>> -----END PGP SIGNATURE-----
>>>
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>>
>>
>>
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
>>
>
>
>
> --
> С уважением,
> Анатолий Шарифулин.
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>



-- 
WBR, Yuri Pac

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