13. Изменения в ZF2.
Почему нужны какие-то изменения?
Что не устраивает в 1.x?
1. Слишком много путей делать одни и те же вещи.
2. Сложность в изучении.
3. Неудовлетворительная производительность.
14. Изменения в ZF2:
1. Namespaces
2. Процедура autoloading’а и загрузки плагинов
3. Типизация Exceptions.
4. Тестирование.
5. MVC
6. Унификация документации.
21. Перевод на Namespaces производился в
полуавтоматическом режиме:
https://github.com/ralphschindler/PHPTools
https://github.com/zendframework/zf2/tree/master/working/
working/BC-Breaks.txt
working/PHPNamespacer-MappedClasses.xml
22. Особенности: отсутствие стандарта на
использование namespaces в docblocks.
namespace ZendToolFrameworkClientConsole;
use ZendToolFrameworkRegistry;
class ArgumentParser implements RegistryEnabled {
/**
* setRegistry()
*
* @param ZendToolFrameworkRegistry $registry
* @return ZendToolFrameworkClientConsoleArgumentParser
*/
public function setRegistry(Registry $registry)
{
// ...
return $this;
}
}
24. Проблемы с зарезервированными словами.
interface Zend_Server_Interface
abstract class Zend_CodeGenerator_Abstract
=>
namespace ZendServer;
interface Server
namespace ZendCodeGenerator;
abstract class AbstractCodeGenerator
25. Использование интерфейсов.
interface Adapter {
public function __construct($options, Queue $queue = null);
public function getQueue();
public function setQueue(Queue $queue);
// ...
}
abstract class AbstractAdapter implements Adapter {
// ...
}
class ArrayAdapter extends AbstractAdapter { /* ... */ }
class Db extends AbstractAdapter { /* ... */ }
// ....
class Queue implements Countable {
/**
* Set the adapter for this queue
*
* @param string|ZendQueueAdapter $adapter
* @return ZendQueueQueue Provides a fluent interface
*/
public function setAdapter($adapter)
{}
}
28. Что не удовлетворяет в autoloading’е ZF 1.x:
http://framework.zend.com/wiki/display/ZFDEV2/Proposal+For+Autoloading+In+ZF2
1. Сложности с использованием include_path.
2. Чем глубже ZF library каталог в include_path, тем
медленнее loading.
3. Не поддерживает системы, где присутствуют связи
отличающиеся от 1:1.
4. Проблемы с производительностью даже при
применении байткод кэширования.
5. Не позволяет просто работать с архитектурами, где
компоненты могут быть инсталлированны в
индивидуальные поддеревья.
32. Plugin loading ZF 1.x:
http://framework.zend.com/wiki/display/ZFDEV2/Proposal+for+Plugin+Loading+in+ZF2
1. Plugin loader используется не везде, где следует.
2. Часть функциональности дублируется в классах,
использующих plugin loader.
3. Проблемы с case sensitivity.
4. Производительность!!!
34. Exceptions в ZF 1.x:
a) Один exception класс на компоненту.
b) Все исключения отнаследованы от Zend_Exception, что затрудняет
дальнейшую типизацию Exception'ов.
PHP Standards working group meeting (2009),
планируемое решение для PEAR:
a) Каждая компонента содержит интерфейс-маркер Exception
b) Различные exception классы компоненты декларируются как
имплементирующие указанный интерфейс-маркер, при этом они
наследуют Exception класс или какой-либо более
специализированный SPL exception класс.
39. Проблемы unit тестов в ZF 1.x:
1. Permissions (при распространении ZF в составе
некоторых Linux дистрибутивов).
2. Служебные классы "живущие" вместе с тестами.
3. Обычно не-PHP файлы (конфиги, ...) расположены в
_files. Тем не менее, это требует review для каждой
компоненты в отдельности.
4. Вопросы возможности запуска тестов в параллельном
режиме.
5. Ресурсоемкость.
6. Нет возможности запуска по списку зависимости
компонент.
41. Controller Layer:
1. Сложно в изучении.
2. Используются некоторые "анти-паттерны":
– Zend_Controller_Front является синглетоном;
– Helper broker доступен только через protected члены класса => проблемы
с injecting.
…
1. Многие неотъемлемые части реализации вызывают падение
производительности.
2. Сложности с созданием модульного приложения (недостаточность
примеров + особенности реализации).
3. Возможность выполнения нескольких actions - сомнительная feature.
4. Error handling.
5. Возможность остановить обработку и немедленно передать response.
42. View Layer:
1. Слишком много ответственностей: отслеживание переменных,
фильтров, хелперов, поиск и рендеринг скриптов.
2. Загрузка helpers - очень узкое место в производительности по
причине overloading и подгружаемости плагинов.
3. Система хэлперов сложна для новых пользователей ("где метод
doctype() определен?! Какие параметры он принимает на вход?!")
4. View могут использовать только PHP скрипты, отсутствуют
приспособления для подгружаемости views откуда-либо еще (db, web
services, ...).
5. Layouts представлены в системе, но не обеспечивают возможностей,
кроме как рендеринга нового view.
43. Forms в ZF 1.x:
1. Form и subcomponents реализуют слишком много
ответственностей. Каждая компонента оперирует как минимум
одним встроенным plugin loader’ом и обращается к этим loader'ам
для работы с prefix paths.
2. Будучи доступны как отдельные объекты, указанные plugin
loader'ы могли бы предоставить большую гибкость и улучшить
производительность.
3. Использованный decorator pattern должен быть не частью объекта Form,
а находиться во view layer'е, form объекты при этом должны быть
инъецированы в decorator chains.
49. I18n/L10n
1. Performance.
2. Несоответствия ZF API и PHP API (например в форматах,
поддерживаемых Zend_Date и привычных для PHP
пользователей).
3. Использование статических данных и глобального состояния в
Zend_Locale серьезно осложняет тестирование как Zend_Locale,
так и других компонент.
