Comments 28
некоторая точка входа, которая позволяет из любого места приложения получить доступ к любым объектам
$user_form = $this->getServiceLocator()->get('UserForm');
Не стоит его так использовать. Используйте DI.
+1
Чем плох сервис менеджер в данном случае?
+1
Очень распространенная проблема у новичков — злоупотребляют сервис менеджером.
Мы сервис менеджер используем только в Module.php, где он выполняет роль DI, а контроллеры/вьюхелперы/сервисы даже не знают о его существовании.
Тестирование, я б сказал, становится адом.
Мы сервис менеджер используем только в Module.php, где он выполняет роль DI, а контроллеры/вьюхелперы/сервисы даже не знают о его существовании.
Тестирование, я б сказал, становится адом.
+1
У вас будет вместо вызова локатора — объект формы как параметр конструктора, либо сеттера (зависит от конфигурации). И соответственно эти зависимости контролера/сервиса должны быть описаны (Zend\Di\Definition) в контексте DI (в zf из коробки есть авто связь (wire) по подсказкам типов, как вариант (RuntimeDefinition) ).
0
А не могли бы привести пример в виде кода? Меня даже больше интересует не сам DI — с ним более менее ясно, а тесты. Что именно тестируется и как. Давно ищу какую-нибудь толковую статью по тестированию ZF2. Интересуют тесты не самого ZF2, а бизнес логики, конечно.
0
Тут не особо зависит zf2 или что-то другое. Общий принцип такой:
Т.е. тестируется взаимодействие с зависимостью (при вызове someSuperMethod должен вызваться someMethod с параметрами). Так же можно делать фейковые возвраты при помощи andReturn. В примере библиотека моков — Mockery.
public function test_something_should_do_something()
{
$dependency = Mockery::mock('SomeBusinessServiceClass')
->shouldReceive('someMethod')
->with('someParams')
->once()
->getMock();
$object_under_test = new ObjectUnderTest($dependency);
$object_under_test->someSuperMethod();
}
Т.е. тестируется взаимодействие с зависимостью (при вызове someSuperMethod должен вызваться someMethod с параметрами). Так же можно делать фейковые возвраты при помощи andReturn. В примере библиотека моков — Mockery.
0
Это я понимаю и видел много примеров уровня «hello word». Интересно бы было посмотреть тесты из реального приложения, желательно большого и со сложной бизнес логикой. Буду рад, если сможете показать куски кода из каких-нибудь ваших проектов или дадите ссылку на статью, где это приводится.
0
Тем что это SL, а не DIС. Это ничем не лучше синглтонов.
А может и даже хуже, с синглтоном я хоть быстро найду что за «UserForm».
А может и даже хуже, с синглтоном я хоть быстро найду что за «UserForm».
0
Зендовский роутинг пугает :)
+3
А можно я тут немного попиарюсь :)? Если вам интересен Twig под ZF2 попробуйте вот этот модуль: он очень классно покрыт тестами, и вообще просто замечательно и без всяких проблем работает (установка возможна как вручную, так и через Composer).
+2
Я до сих пор не понимаю шаблонизаторов под php. Short tags и альтернативный синтаксис — вот тебе и шаблонизатор. Тем более Zend\View\Renderer\PhpRenderer довольно мощный, по сравнению с Zf1.
Можете пояснить, в чем преимущества использования шаблонизатора в разрезе php?
Можете пояснить, в чем преимущества использования шаблонизатора в разрезе php?
0
Вот плюсы, которые выделяю для себя я:
Да, против первых двух пунктов есть тестирование и код ревью, но мне удобнее недопустить появления этих проблем.
- я точно уверен, что верстальщик не поломает PHP-код внутри шаблона,
- я точно уверен что ленивый программист не перенесет часть логики в шаблон (встречал я и запросы к БД в шаблонах),
- по мне, код Twig-шаблонов получается более компактным и читабельным.
Да, против первых двух пунктов есть тестирование и код ревью, но мне удобнее недопустить появления этих проблем.
+1
Твиг не использовал. Возникли вопросы:
что произойдет если верстальщик поломает разметку Твига?
имхо, от такого программиста можно ожидать вещей пострашнее, чем запросы в шаблонах
я точно уверен, что верстальщик не поломает PHP-код внутри шаблона
что произойдет если верстальщик поломает разметку Твига?
я точно уверен что ленивый программист не перенесет часть логики в шаблон (встречал я и запросы к БД в шаблонах)
имхо, от такого программиста можно ожидать вещей пострашнее, чем запросы в шаблонах
0
самый большой плюс для меня — автоматическая защита от XSS. Так же в twig мне очень нравится идея наследования и переопределения блоков.
+1
используется встроенный в фреймворк шаблонизатор
Что за встроенный в ZF2 шаблонизатор?
0
skeleton-application есть на packagist.org, поэтому можно обойтись без --repository-url=«packages.zendframework.com» при создании проекта
composer search zendframework/skeleton-application
0
Зря в офф. туториале не упомянули про кеширование конфигов.
В module_listener_options обязательно включите кеширование конфигов или все это чудо будет мержиться на лету :-)
'cache_dir' => 'data/cache',
'config_cache_key' => 'your_key',
'config_cache_enabled' => true
В module_listener_options обязательно включите кеширование конфигов или все это чудо будет мержиться на лету :-)
'cache_dir' => 'data/cache',
'config_cache_key' => 'your_key',
'config_cache_enabled' => true
0
Заранее прошу прощения у фанов ZF2.
Очень правильно сделали, что
Кто-то мне объяснит почему Zend Framework 2 популярнее чем Symfony 2?
Очень правильно сделали, что
первыми решил изучить Zend Framework 2Я сейчас после Symfony 2 пытаюсь изучить Zend Framework 2 — это ужасно. Если изучая первый я восхищался как же все хорошо сделано, то с ZF2 я прикладываю всю свою силу воли. чтобы не застрелиться.
В итоге, более-менее удовлетворительное по функционалу приложение я смог создать после прочтения книги.Я бы эту фразу выделил жирными красными буквами. Довольно сложное приложение с кучей сервисов на Symfony 2 я написал после прочтения официльного туториала. Ну и по ходу подглядывал в их же справочник и Поваренную книгу.
Кто-то мне объяснит почему Zend Framework 2 популярнее чем Symfony 2?
0
Sign up to leave a comment.
Пример разработки блога на Zend Framework 2. Часть 1. ZendSkeletonApplication