Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Ура, а то притих что-то когда-то любимый фреймворк.
Во всех крупных коммерческих проектах используем ZF2, в принципе самый гибкий из доступных фреймворков. Вот если бы из него выкинули Zend\Db, Zend\Form(используем чисто Zend\InputFilter), и т.д. было бы вообще круто. Из-за чего ZF2:
1. Удобная система модулей (многие модули находятся в отдельных репозиториях, и используются во многих проектах, да и зону ответственности намного проще находить);
2. Удобный роутинг (не одним Literal и Segment единым, можно спокойно сделать собственные типы роутинга с различными дополнительными проверками (например проверка на существование записи с таким именем в БД));
3. Удобный EventManager (подписаться на EVENT_ROUTE для определенного класса, для общего предка, или к примеру для одного модуля, к примеру чтобы заменить layout, также можно много всего интересного делать до входа в Контроллер как проверка авторизации, валидация запроса, и т.д.);
4. Удобный ServiceLocator (Invokables, Abstract Factories, Factories, Callbacks, etc — очень гибко можно это все настроить под себя);
5. Удобные View'шки (я больше предпочитаю нативные шаблонизаторы, так как php в этом плане справляется со всем сам);
6. Удобные консольные роуты;
7.Удобная система конфигов (в начале грузится application.config.php, потом global.php, потом если есть local.php в котором все локальные конфиги прописаны, и они не влияют на остальные, потом по модулям). В итоге получается общий конфиг с особенностями локальной конфигурации.
Ну и многое другое. Очень много писать на самом деле.
1. Удобная система модулей (многие модули находятся в отдельных репозиториях, и используются во многих проектах, да и зону ответственности намного проще находить);
2. Удобный роутинг (не одним Literal и Segment единым, можно спокойно сделать собственные типы роутинга с различными дополнительными проверками (например проверка на существование записи с таким именем в БД));
3. Удобный EventManager (подписаться на EVENT_ROUTE для определенного класса, для общего предка, или к примеру для одного модуля, к примеру чтобы заменить layout, также можно много всего интересного делать до входа в Контроллер как проверка авторизации, валидация запроса, и т.д.);
4. Удобный ServiceLocator (Invokables, Abstract Factories, Factories, Callbacks, etc — очень гибко можно это все настроить под себя);
5. Удобные View'шки (я больше предпочитаю нативные шаблонизаторы, так как php в этом плане справляется со всем сам);
6. Удобные консольные роуты;
7.Удобная система конфигов (в начале грузится application.config.php, потом global.php, потом если есть local.php в котором все локальные конфиги прописаны, и они не влияют на остальные, потом по модулям). В итоге получается общий конфиг с особенностями локальной конфигурации.
Ну и многое другое. Очень много писать на самом деле.
Symfony 2 не пробовали?
Symfony тоже используем, но все же не все в нем нравится, к примеру:
1. Конфиги в yaml'е или xml'е, я понимаю, что Symfony — это некий порт Spring на PHP, но в PHP есть отличные массивы для таких нужд, которые намного проще читать, чем yaml либо xml. Да, это субъективное впечатление, но все же нормально использовать массивы в качестве конфига в Symfony сложно (в документации некоторые вещи не предоставляют примера конфига на чистом PHP, в итоге просто привыкаешь);
2. Assetic — задумка хорошая, в принципе для простых нужд очень удобная, но: если используете requirejs и coffeescript, с включенным файл вотчером, которые компилирует coffeescript, то Assetic чего-то под видом js-а отдает coffeescript файлы, так как он считает что нужно подключить конвертер для этих файлов, либо со стороны php, либо со стороны клиент-сайда. Исправить это смогли только отключив Requirejs Bundle. Таких неожиданностей поведения никто не ожидал;
3. Очень много кода получается для форм, к примеру мы используем PostgreSQL, и нужно было в select вывести пользователей у которых есть определенный пермишн, пермишины хранятся в json колонке у юзера. В итоге пришлось:
— добавить NativeQuery над Entity (так как работа с JSON полем в Doctrine нет);
— описал NativeEntityType для того, чтобы подсунуть NativeQueryLoader;
— сделали NativeQueryLoader (стандартный не работает с query для PostgreSQL);
— это все обложил конфигом;
В ZF2 я бы мог просто в InputFilter передать репозиторий, и при построении Input'а задать ему валидатор: new Validator\InArray($users) и на этом все.
Да, это все субъективно, Symfony хороший фреймворк, но некоторые вещи в нем не сильно удобно сделаны.
1. Конфиги в yaml'е или xml'е, я понимаю, что Symfony — это некий порт Spring на PHP, но в PHP есть отличные массивы для таких нужд, которые намного проще читать, чем yaml либо xml. Да, это субъективное впечатление, но все же нормально использовать массивы в качестве конфига в Symfony сложно (в документации некоторые вещи не предоставляют примера конфига на чистом PHP, в итоге просто привыкаешь);
2. Assetic — задумка хорошая, в принципе для простых нужд очень удобная, но: если используете requirejs и coffeescript, с включенным файл вотчером, которые компилирует coffeescript, то Assetic чего-то под видом js-а отдает coffeescript файлы, так как он считает что нужно подключить конвертер для этих файлов, либо со стороны php, либо со стороны клиент-сайда. Исправить это смогли только отключив Requirejs Bundle. Таких неожиданностей поведения никто не ожидал;
3. Очень много кода получается для форм, к примеру мы используем PostgreSQL, и нужно было в select вывести пользователей у которых есть определенный пермишн, пермишины хранятся в json колонке у юзера. В итоге пришлось:
— добавить NativeQuery над Entity (так как работа с JSON полем в Doctrine нет);
— описал NativeEntityType для того, чтобы подсунуть NativeQueryLoader;
— сделали NativeQueryLoader (стандартный не работает с query для PostgreSQL);
— это все обложил конфигом;
В ZF2 я бы мог просто в InputFilter передать репозиторий, и при построении Input'а задать ему валидатор: new Validator\InArray($users) и на этом все.
Да, это все субъективно, Symfony хороший фреймворк, но некоторые вещи в нем не сильно удобно сделаны.
Понятно. Я раньше тоже ZF2 юзал. Теперь Symfony2. Насчёт конфигов можно же разные форматы использовать, в том числе и на PHP. Как и в ZF2 тоже можно другие форматы.
Несколько примеров того, почему это удобнее:
1. Массивы парсятся намного быстрее чем yaml, так как это нативная вещь в языке (несколько раз видел как человек import'ами в Symfony зациклил парсинг)
2. Работает автодоплнение когда ты пишешь название класса, и ты можешь спокойно перейти в этот класс:
К примеру:
И в любой момент можно найти использования с помощью стандартных средств IDE.
3. Есть возможность использовать нативные возможности языка, и это часто помогает, к примеру на CI я получаю параметры для базы в виде ENV параметров, и я могу спокойно сделать так:
Ну опять же, это все субъективно, да yaml считается человекочитаемым форматом, но нативные массивы не сильно уступают от него
1. Массивы парсятся намного быстрее чем yaml, так как это нативная вещь в языке (несколько раз видел как человек import'ами в Symfony зациклил парсинг)
2. Работает автодоплнение когда ты пишешь название класса, и ты можешь спокойно перейти в этот класс:
К примеру:
"service_manager" => [
"invokables" => [
"api:device" => \Api\Service\Device::class,
],
]
И в любой момент можно найти использования с помощью стандартных средств IDE.
3. Есть возможность использовать нативные возможности языка, и это часто помогает, к примеру на CI я получаю параметры для базы в виде ENV параметров, и я могу спокойно сделать так:
'doctrine' => array(
'connection' => array(
// Configuration for service `doctrine.connection.orm_default` service
'orm_default' => array(
// connection parameters, see
// http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/configuration.html
'params' => array(
'host' => (getenv('WERCKER_MYSQL_HOST'))?getenv('WERCKER_MYSQL_HOST'):'localhost',
'port' => (getenv('WERCKER_MYSQL_PORT'))?getenv('WERCKER_MYSQL_PORT'):'3306',
'user' => (getenv('WERCKER_MYSQL_USERNAME'))?getenv('WERCKER_MYSQL_USERNAME'):'root',
'password' => (getenv('WERCKER_MYSQL_PASSWORD')) ? getenv('WERCKER_MYSQL_PASSWORD') : 'freeware',
'dbname' => (getenv('WERCKER_MYSQL_DATABASE'))?getenv('WERCKER_MYSQL_DATABASE'):'orm-test',
)
),
),
Ну опять же, это все субъективно, да yaml считается человекочитаемым форматом, но нативные массивы не сильно уступают от него
1. Насколько я знаю, влияние на произодительность минимально, yaml файлы парсятся только при изменении в дев-режиме. На продакшене парсятся вообще только при очистке кэша или первом запуске.
2. В phpstorm с плагином symfony2 все работает. ЧЯДНТ? :)
3. Советую пройтить по документации еще раз. Как раз то что вам нужно symfony.com/doc/current/cookbook/configuration/external_parameters.html Просто добавьте переменным окружения SYMFONY__ префикс и они буду доступны в yaml файле. Ну или же используйте
2. В phpstorm с плагином symfony2 все работает. ЧЯДНТ? :)
3. Советую пройтить по документации еще раз. Как раз то что вам нужно symfony.com/doc/current/cookbook/configuration/external_parameters.html Просто добавьте переменным окружения SYMFONY__ префикс и они буду доступны в yaml файле. Ну или же используйте
imports:
- { resource: parameters.php }
1. все конфиги symfony (неважно, yml, xml или php) парсятся только один раз, после чего компилируются в php.
на prod режиме это происходит только один раз при очистке кеша (читай деплое)
на dev, test и т.п. режимах — только при редактировании файлов с конфигами.
2. не в курсе как там с netbeans и прочими vim'ами, но в phpStorm'е есть чудесный плагин, который решает все проблемы конфигов — автодополнение, переход к файлу с классом, подсказка по методам из контейнера и много еще чего.
3. никто не мешает вам описать точно также в php-конфигах на симфони. но в целом — согласен, yml формат такого не позволяет
на prod режиме это происходит только один раз при очистке кеша (читай деплое)
на dev, test и т.п. режимах — только при редактировании файлов с конфигами.
2. не в курсе как там с netbeans и прочими vim'ами, но в phpStorm'е есть чудесный плагин, который решает все проблемы конфигов — автодополнение, переход к файлу с классом, подсказка по методам из контейнера и много еще чего.
3. никто не мешает вам описать точно также в php-конфигах на симфони. но в целом — согласен, yml формат такого не позволяет
не одним Literal и Segment единым, можно спокойно сделать собственные типы роутинга с различными дополнительными проверками (например проверка на существование записи с таким именем в БД)
Вот этого мне так не хватает после друпала, не поделитесь ссылкой на документацию этой возможности или примером?
Вообще я подумываю написать статью о возможностях по кастомизации ZF2, но вот пример моего RouteMatch, для статических страниц с локализацией, лежащих в БД (с путями там же): pastebin.com/iBGqxk8x а вот пример использования этого роута: pastebin.com/dRN3d7Vm
Вообще на самом деле ZF очень мощный в плане кастомизации, вот пример моего одного Контроллера: pastebin.com/HQyC6bhV
входящие параметры в экшены — это и Entity, и Сервисы, и Фильтры (которые автоматически создаются на основе Entity).
К примеру метод create общий для создания и редактирования (оно автоматически определяет оригинальную Entity и инжектит оригинальные данные в фильтр, а потом дополняет полученными из POST).
Да, много из этого доступно из-за моей ORM'ки, но ZF позволяет себя расширять очень удобно.
Вообще на самом деле ZF очень мощный в плане кастомизации, вот пример моего одного Контроллера: pastebin.com/HQyC6bhV
входящие параметры в экшены — это и Entity, и Сервисы, и Фильтры (которые автоматически создаются на основе Entity).
К примеру метод create общий для создания и редактирования (оно автоматически определяет оригинальную Entity и инжектит оригинальные данные в фильтр, а потом дополняет полученными из POST).
Да, много из этого доступно из-за моей ORM'ки, но ZF позволяет себя расширять очень удобно.
Zend однако отстал в развитии, мы уже давно в компании используем Symfony 2 и довольны как слоны.
У меня на работе часто начинаются споры между ZF2 и Symfony2 и такие споры длятся не один час. В результате каждый остается со своим мнением. Я считаю что для каждой задачи свой инструмент. Я сам разрабатываю на ZF2 и он мне нравится, но иногда поглядываю и на Symfony 2. Но вот например мой блог на WP. настроить на сервере со всеми SEO плагинами и модулями кеширования у меня ушло до часа времени, и мне там совсем не нужен ZF2 или же Symfony 2. Я этим сообщением хотел сказать что каждый framework или CMS по своему хороши, так сказать у каждого есть свой супер удар :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анонсирован Zend Framework 3 Roadmap