avril
2011
Un article de Nighty
Ce soir a eut lieu un Webinar dont le thème était les patterns de Zend Framework 2. Matthew Weier O’Phinney, Lead Project du Zend Framework, nous a présenté ce soir quelques concepts clés sur lesquels s’articuleront le futur ZF2.
Sans en faire un résumé complet, les slides et le podcast seront de toutes manières sûrement disponibles d’ici quelques jours, je vais essayer de vous en toucher un mot rapide, car pas mal de choses intéressantes y ont été dites, notamment quelques dates.
Quelques dates
Inutile de faire durer le suspense, quelques estimations de date nous ont été communiquées ce soir. Pour faire court, il est question d’une milestone fin mai, qui sera suivie d’une version de preview.
Plus important : la bêta est prévue pour cet été, quant à la release stable il faudra attendre la fin 2011 si tout va bien.
Compatibilité
Sans surprise, la rétro-compatibilité sera cassée par cette version majeure, mais ça on le savait déjà. Ce qui n’est pas tout à fait facile à anticiper, c’est dans quelle mesure ? J’ai cependant bon espoir qu’une application Zend Framework moderne (utilisant Zend_Application) puisse migrer progressivement sans trop de casse.
Autoloader
Au niveau de l’autoload, on a revu ce soir quelques unes des informations que l’on avait pu voir traîner ici et là.
Une utilisation massive des namespaces en complément des préfixes actuels est à prévoir, mais là encore ce n’est pas une surprise. La possibilité d’utiliser l’ancien système de préfixe devrait aider à migrer les applications Zend Framework 1.x.
Quoi qu’il en soit, les nouveautés sont très intéressantes, tel que l’autoloader classmap, basé sur un simple tableau associatif de correspondance classe / fichier et donc beaucoup plus performant.
A ce niveau, l’élément qui m’a incontestablement le plus emballé est le remplaçant de l’actuel PluginLoader, à savoir le PluginBroker. Cela se présente comme une interface Broker qui utilise un objet implémentant l’interface ShortNameLocator.
L’implémentation d’un pattern Strategy entre le Broker et le Locator permet de changer ce dernier en cours d’exécution, et donc de modifier dynamiquement la façon dont sont chargées les plugins. Cela permet pas mal de fantaisies, telles que la mise en cache des plugins chargés… Il semblerait aussi que le mécanisme de chargement des plugins sera plus transparent et facile à appréhender.
Il m’a également semblé que l’exemple PluginBroker qui nous a été montré utilisait un classmap loader, pour des raisons de performances.
EventManager
L’EventManager est prévu pour deux utilisations spécifiques :
- En tant que classe autonome, utilisée par composition conjointement avec une classe pouvant déclencher des évènements.
- En tant qu’EventManager statique, un singleton dont l’instance est récupérable partout par l’habituelle méthode statique getInstance().
Cette nouveauté m’a beaucoup emballée, et permettra de greffer de nombreux comportements annexes aux classes métiers (logging, vidage de cache…) sans mélanger le métier et les tâches “utilitaires”. L’utilisation conjointe de Closures et de l’EventManager est très prometteur…
Une question que je me pose, je ne pense pas que le sujet ait été abordé durant ce Webinar mais j’ai peut-être raté un épisode : ce système d’évènement remplacera-t-il l’actuel fonctionnement des Zend_Controller_Plugin ?
DependencyInjection
Difficile de parler de ce point. Pas parcequ’il n’y a pas grand chose à en dire, mais au contraire car il y en aurait beaucoup !
L’utilisation massive de Closures conjointement à un DependencyInjector est réellement pleine de promesse, le DependencyInjector se chargeant de permettre l’accès aux services ainsi que l’interdépendance des services les uns avec les autres.
Un dernier exemple nous a permis d’entrevoir le fonctionnement du futur MVC, ou le dispatcher utilisera un DependencyInjector afin d’associer aux contrôleurs les services qu’ils utilisent, sans pour autant que ne soit chargés les éléments qui ne sont pas utilisés.
Il sera possible de paramétrer le DI soit par programmation, soit par configuration.
Autres éléments
Comme évoqué plus haut, ce billet n’est pas un résumé complet…
Il a entres autres été questions d’une réorganisation des exceptions pour tirer profit des exceptions de la SPL plutôt que de les sous-classer par composant. En héritant des exceptions de la SPL et en implémentant des interfaces propres aux composants, il sera possible de définir d’affiner grandement le traitement des exceptions. En espérant que ça permettre de clarifier la détection des erreurs 404 par le plugin errorHandler…
L’uniformisation de la définition des options a également été évoquée, par l’habituelle méthode setOptions ou par un objet de configuration propre à chaque composant.
Il a enfin été question la refonte du MVC, basée sur trois interfaces “légères” : Request, Response et Dispatchable, la troisième utilisant la première pour générer la seconde.
En conclusion
Je suis vraiment très enthousiaste vis à vis de ce qui a été présenté ce soir, et je pense que le prochain Zend Framework a vraiment beaucoup à nous offrir. L’attente va être longue !
Le webinar a été vraiment très instructif et je vous invite à consulter les slides quant ils seront en ligne (probablement à cette adresse d’ici quelques jours, la création d’un compte utilisateur est nécessaire : http://www.zend.com/en/resources/webinars/ ).
Edition du 08/04/2011 :
juste pour vous signaler la mise à disposition du Webinar sur le site de Zend (nécessite une inscription préalable) http://www.zend.com/en/webinar/Framework/70170000000bX3J-webinar-zf-2-patterns-20110330.flv