> Perl это культура. К перлу прилагается CPAN, где этих фреймворков как > собак не резанных. И грамотный перловщик держит в голове их штук пять, > выбирая наиболее подходящий под конкретный проект.
Кстати, о фреймворках... Не совсем по тематике рассылки, но не знаю другой такой по уровню квалификации подписчиков. Я тут последние недели 3 пребываю в поиске идеального фреймоворка, и никак не могу не определиться. Существует их действительно огромное количество, и все такие разные, что я столкнулся с проблемой буриданова осла. Попробую описать свой "идеальный газ" или то, что я ищу. Итак. 1. Экстремальная простота и понятность. Наверно, это грех, но меня очень привлекают фреймворки с крутой "learning curve". Однако могу объяснить почему. Не буду спорить с тем, что один хороший гуру, набитый доверху знаниями нескольких фреймворков да еще для нескольких языков, это круто и гораздо лучше пятерых неофитов. Но существуют ситуации, когда невозможно найти ни денег для зарплаты гуру, ни самого гуру вообще в силу удаленности от культурных центров и низкой плотности населения в месте выполнения проекта. Проекты ведь разные бывают, не только коммерческие... 2. Масштабируемость. Фреймворк должен не позволять программистам писать спаггети-код, делая со временем проект неуправляемым. Функциональность должна наращиваться по кирпичикам просто включением новых компонентов с сохранением устойчивости всего здания. И лучше, когда можно брать со стороны уже готовые компоненты, легко интегрирующиеся в систему. Например, добавление форума не должно менять look&feel сайта или предъявлять какие-то дополнительные требования к принятой схеме аутентификации на сайте. Слабая связанность компонентов часто бывает приятна. 3. Простота добавления дополнительной логики в уже работающую систему или какую-то её часть. То есть, например, сайт уже создан и работает, но вдруг пришел "большой босс" и попросил добавить логгирование всех запросов (или только запросов к некоторым частям сайта) в СУБД, для последующего анализа в стиле hotlog. Не хочется лезть в каждый *.php и добавлять туда по необходимости include. Хочется просто добавить дополнительное действие в какой-нибудь ExecutionFilter или ActionChain. 4. Гибкость представления. Для web-разработки это очень важно. Здорово, когда для добавления в любое место интерфейса глобально или для части сайта некоторого блока (курс валют, текущая загрузка сервера, температура за бортом,...) достаточно произвести всего лишь несколько пасов руками. В каких-то фреймворках предлагается разбивать страницу на блоки и подблоки в древовидную структуру, для каждого подблока делать рендеринг, результат возвращать в блок верхнего уровня и рендерить далее его, и так до корня. В каких-то просто на уровне шаблонов делать include хедера, футера и чего там еще... Другие предлагают наследовать шаблоны (или view-компоненты) для каждого модуля от некоторого базового шаблона и переопределять те блоки, которые необходимо, как, например, в django. В случае с шаблонами не совсем понятно как сделать, например, в некотором блоке показ курса валют глобально по сайту, а в одном разделе сайта вместо курса валют в том же блоке показывать что-то другое, и при этом рендеринг курса валют сделать глобально и в других разделах им не заниматься, а только в каком-то конкретном разделе переопределить поведение блока. Zope'овское наследование контекста и METAL эту задачу решают очень легко, а главное - понятно. 5. Наличие уже готовой функциональности, базовой для большинства web-приложений, как то: аутентификация и авторизация, валидаторы форм, логгирование, а желательно еще и профилирование и т.д. 6. Язык фреймворка должен иметь как можно больше привязок к внешним библиотекам. Не только то, что содержится в PECL, а, например, поддержка CORBA (короче, CPAN рулит). Или вот еще поддержка тредов... Это несколько специфическое пожелание для web, но для меня важное. Я смотрел: 1. Turbogears. Требует python 2.4, которого в Sarge нет 2. Twisted.web+Nevow. Очень любопытный фреймворк. В некоторой степени присутствует MVC, возможно наследование контекста при рендеринге шаблонов в стиле Zope. Присутствует документация, местами даже понятная. Но по пункту 5 тут, по-моему, слабо на фреймворк тянет. 3. PHP Mojavi По пункту 1 этот фреймворк вне конуренции. 2, 3, 5 тоже присутствуют. Можно сказать, имется полноценный MVC. В качестве шаблонов использется сам PHP (очень похоже на то, как используется JSP). Рендеринг сложной страницы, состоящей из подблоков, осуществляется путем наследования View от базового класса, в котором рисуются хедеры, футеры и т.д., а содержимое поблоков определяется в классе-потомке. Хорошее решение, но не такое элегантное, как METAL. Ну кроме того... PHP. 4. Catalyst MVC-фреймворк на Perl. С разбегу разобраться не получилось. Реализация контроллера очень красивая, классы модели генерируются скриптом-хелпером на основании схемы СУБД. Правда, не скажу, что этот scaffolding интуитивно понятен. В качестве View предлагается использовать Template Toolkit или другой шаблонный движек на выбор. Не понял, как там сделать наследование контекста... Документация куцая. Но CPAN... 5. Django Просто и понятно. Для контент-ориентированных сайтов просто идеален. Но все же у меня есть непонятности по пунктам 2, 3 и даже 4. 6. Zope3 Фреймворк-мечта. Присутствуют все пункты в полном объеме, кроме пункта 1. Несмотря на то, что уже и книжка есть, сам фреймворк настолько объемен, что непонятно какого объема должна быть "Библия Zope3", чтоб там не только были общие концепции типа описания компонентной архитектуры, но практические описания. Например, несколько часов потратил, чтоб понять как на ZCML описать и зарегистрировать иерахическое меню. В книжке об этом ни слова, а по APIDOC вообще непонятно, чем menuItem отличается от subMenuItem функционально. И таких мелочей полно. Сложно понять, как именно надо использовать модули (а их много), входяшие в zope3, чтоб все было кошерно. Подозреваю, что много чего унаследовано от zope2, но я никогда его не использовал. Короче, хоть и есть релиз, но достаточным количеством документации и коммьюнити этот фреймворк еще не оброс. Кто-нибудь может рассказать, как он определялся со своим выбором? Может я ерунду написал? Всё-таки я не совсем программист. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
