Подбор PHP фреймворков

[Wicked]

Я не нашёл способа подключить в нескольких модулях один и тот же partial template, пришлось копировать файл с этим шаблоном во всемодули.

Видимо, ты не осилил документацию по Partial'ам - http://www.symfony-project.org/book/1_0/07-Inside-the-View-Layer#Partials
Конкретно я говорю про этот пример:

// Include the myapp/templates/_mypartial3.php partial
// It is considered as part of the 'global' module
<?php include_partial('global/mypartial3') ?>

-~{}~ 03.01.08 16:31:

Минусы:
1. ОЧЕНЬ большое количество различных соглашений об именовании файлов, классов, методов, функций, настроечных параметров конфигурационных файлов, и много чего ещё. Документация по этим соглашениям разбросана по документации и не всегда полная. Не зная этих соглашений запустить приложение не получиться.

С этим согласен.

Часто встречаются баги.

На своей жизни видел всего два: один в итоге оказался этим - http://bugs.php.net/bug.php?id=41874. Второй - http://trac.symfony-project.com/ticket/2520 .

2. Достаточно костная архитектура, трудно поддаётся расширению. Очень много различных настроек, с которыми приходиться разбираться, чтобы запустить приложение.

Плагины (которых, кстати, туева хуча), хелперы, партиалы, IOC посредством factories.yml, и т.д. - довольно неплохой набор. У меня пока что не было масштабных задач по расширению symfony, так что реалий я не знаю, но интуиция подсказывает мне все таки с тобой не согласиться.

3. Отсутствие шаблонизатора. Для меня это большой минус, так как много времени уходит на написание шаблонов. Часто приходиться использовать копи-пасте. Из-за отсутствия шаблонизатора, кастомизация сгенерированных скриптов достаточно сложная.

PHP сам себе шаблонизатор. Лично мне такая "фича" нравится больше, чем перспектива учить еще один язык разметки типа smarty.

4. ОЧЕНЬ плохое качество кода. Методы по 300 строк кода для этого фрэймворка практически норма.

Это единственный критерий, по которому ты оцениваешь качество кода?

Вобщем, не удивительно, что у программистов появляется такое стойкое отвращение к фрэймворкам, если их знакомство начиналось с Symfony, самого раскрученного фрэймворка. Тем не менее, не думаю, что менее раскрученные фрэймворки будут обязательно хуже, просто у Symfony маркетологи оказались лучше чем программисты.

Я сначала трогал кейк и прадо. Не прижились. С симфони пошло на порядок лучше. Но симфони требует от программиста понимания, что у этого фреймворка довольно большой потенциал. Поэтому я, прежде чем что-то сделать, кропотливо изучал документацию, посему не делал многочисленные велосипеды.

Насчет Propel мне сказать нечего, т.к. использовал только Doctrine.

 

[atv]

Видимо, ты не осилил документацию по Partial'ам

Видимо пропустил, но это не единственный случай дублирования кода шаблонов. Вообще, отсутствие шаблонизатора ведёт к дублированию кода шаблонов.

На своей жизни видел всего два

Я уже написал, что основную часть багов нашёл в генераторе админки, без которой этот фрэймворк вообще не интересен.

У меня пока что не было масштабных задач по расширению symfony, так что реалий я не знаю, но интуиция подсказывает мне все таки с тобой не согласиться.

Вопрос в том, интуиция ли?

PHP сам себе шаблонизатор. Лично мне такая "фича" нравится больше, чем перспектива учить еще один язык разметки типа smarty.

Вопрос о шаблонизаторах я обсуждал в соответствующей теме, здесь я отметил что его в Symfony нет. Для кого это не важно, тот не обратит внимания.

Это единственный критерий, по которому ты оцениваешь качество кода?

Нет, не единственный, но после этого все остальные теряют своё значение. Попробуй написать к Symfony какое нибудь расширение, тогда поймёшь о чём я. А если попробуешь его оптимизировать, тогда ты полностью ощутишь, что такое методы по 300 строк.

Поэтому я, прежде чем что-то сделать, кропотливо изучал документацию

Аналогично. Я тоже придерживаюсь этой практики, и мой текущий проект заставил меня довольно глубоко ознакомиться с фрэймворком.

Я для себя сделал вывод, для остальных указал составляющие своего вывода, а дальше пусть каждый решает сам.

 

[dark-demon]

> сделать свой view с использованием любимого шаблонизатора это сложность?

сделать свой фреймворк с использованием любимых библиотек это сложность?

 

[Black Raven]

Автор оригинала: dark-demon
> сделать свой view с использованием любимого шаблонизатора это сложность?

сделать свой фреймворк с использованием любимых библиотек это сложность?

модель mvc предназначена для разделения слоев и подразумевает что View МОЖЕТ МЕНЯТЬСЯ и предоставляет для этого удобное решение. (я не про код говорю, а про паттерн)

фреймворк это, как правило, решение для команды разработчиков, куда люди могут приходить и уходить.
если ты один, то ничего в этом сложного нет.

atv
насчет админ генератора согласен - через конфиги довольно неудобно добираться до нужных полей. это связано с тем, что для преобразования из имени поля в таблице в геттеры используются 2 разные функции. одна пропеловская, одна в самом админ генераторе. большинство вопросов решается созданием своих шаблонов и "компонентов".

прости, но у меня создалось впечатление, что ты ну очень не любишь документацию. если ее читать, то многое становится ясно, потому что то что ты говоришь о layout.php это бред. сложностей 0, если читать доки.

Wiked
Ну сравни плз Symfony с каким-нибудь другим фреймворком, который использовал, а?

 

[dark-demon]

> mvc предназначена для разделения слоев и подразумевает что View МОЖЕТ МЕНЯТЬСЯ

более того - и контроллер и модель МОГУТ меняться. вот мозьми и поменяй все контроллеры модели и вьюхи. что тогда останется от фреймворка? голый мвц? и кому он такой нужен?

 

[atv]

прости, но у меня создалось впечатление, что ты ну очень не любишь документацию.

С этим фрэймворком я только и делал что изучал документацию и даже при этом не сразу мог получить результат, так как в фрэймворке существует много неявностей (как раз из-за большого количества соглашений), которые описаны где-то в другом месте документации и на них приходилось выходить методом дебага.

большинство вопросов решается созданием своих шаблонов и "компонентов".

Я таки пошёл по этому пути, но и тут наткнулся на плохое качество кода. Получилось, что то ради чего пал выбор на фрэймворк, пришлось процентов на 25 переделывать, и на это ушло столько времени, что выигрыш от использования Symfony приблизился к нулю.

потому что то что ты говоришь о layout.php это бред.

Может быть, где об этом сказано в документации? А вообще, я смотрел, также, доку на XSLT плагин к Symfony.

Ещё больше документации я люблю читать код, так как в документации могут быть упущения. А читать код Symfony - это занятие не из приятных.

Более того, плохое качество кода плохо не только для пользователей фрэймворка, но и для авторов. Это означает, что баги будут исправляться долго, при исправлении могут добавиться новые, полученный код может оказаться очень не оптимальным, добавление новой функциональности также затруднено. Поэтому, качество кода проекта должно стоять на первом месте, как залог успешного развития.

Для примера, почитайте код проекта SimpleTest или LIMB, даже отсутствие обильной документации не сказывается на освоении проекта, а в Symfony из документации не вылазишь.

 

[itprog]

Более того, плохое качество кода плохо не только для пользователей фрэймворка, но и для авторов.

Я недавно смотрел код symphony 1.1, стало намного лучше, избавились наконец-то от использования функций.

Если интеграция с ORM PROPEL заявлена как плюс фрэйворка, то и минусы PROPEL имеют отношение к фрэймворку. А без ORM, а тем более генератора админки, это вообще пустое место.

Кроме интеграции PROPEL, есть интеграция Doctrine, которую и рекомендуют. А минусы фреймворк перенимает, если бы он был полностью завязан на propel, а это же не так - хочешь не используй?

 

[gray07]

В симфони есть шаблонизаторы как плагины

http://trac.symfony-project.com/wiki/SymfonyPlugins#Viewlayerreplacements