La vitrine de ma veille technologique

Maitre-corbeaux.com, en plus d’un mauvais calembour sur mon patronyme, est un site dont la vocation première est de centraliser en un unique point l’ensemble de mon activité internet liée à ma profession de développeur.

En résumé, tous les quart d’heures sont parcourus un ensemble de « feeds » d’activité (flux RSS, Atom, API diverses dont Twitter…) et mon activité est insérée en base, indexée par Lucene et mise à disposition sur le site. Le but de cette mise à disposition de ma veille technologique est multiple :

• Pour retrouver facilement l’ensemble des articles et actus que j’ai pu lire. Je suis le premier consommateur de mon site… quelques mauvaises langues disent d’ailleurs que je suis aussi le seul
• Pour expérimenter certaines choses sur un projet concret mais peu exigeant : depuis sa création, j’ai expérimenté dessus un ORM très basique maison, un moteur de recherche basé sur Zend_Search_Lucene, m’amuser sur certaines API comme Twitter et Pocket…
• Et enfin, avoir une présence sur Internet en tant que professionnel du Web, tout en communiquant très clairement sur mon absence totale de goût en terme de design ! Difficile de nier que ma valeur ajoutée ne se trouve pas en front-end…

Un site open source

Mais maitre-corbeaux.com n’est pas seulement née de la volonté de diffuser ma veille technologique, le site est également open source, et disponible sur Github : https://github.com/lucascorbeaux/maitre-corbeaux.com

Comme mon flux Github est référencé comme source d’activité, cela signifie que le site auto-publie les évolutions de son propre code source.

Le but de cette diffusion du code source, est de pouvoir mettre à disposition un projet complet et fonctionnel basé sur le Zend Framework, plutôt atypique (pas un énième CMS, moteur de blog, CRM ou e-commerce !), et couvert par les tests unitaires (ce sont également mes premières armes sur PHPUnit que j’ai fait sur ce site à sa création…).

Piste d’évolutions

Le site n’a pas connu d’évolution majeure de ses fonctionnalités depuis le départ. Le rythme d’évolution est peu soutenu, et est plus dédié à de petits bugs ponctuels et des améliorations mineures qu’autre chose.

Actuellement, dans l’idée de faire évoluer le site vers ZF2, la couverture de test est en cours d’amélioration. Une fois l’intégralité du site correctement couvert par les tests, la migration (potentiellement lourde et complexe) vers la nouvelle version du framework sera plus sûre…

Tout un tas de pistes d’évolutions sont envisagées, en mode « un jour, peut-être » :

• Flux RSS.
• Possibilité de filtrer les items par source.
• Utiliser Google Docs comme backoffice CMS pour le éditer contenu du site.
• Autre ?

Votre utilisation

Mais alors, à quoi peut bien vous servir maitre-corbeaux.com ?

• À rechercher dans ma veille technologique via le moteur de recherche intégré. Vous trouverez des articles, le plus souvent intéressants, que j’ai eut l’occasion de lire et de RT. Quelques suggestions de recherche :
  • http://www.maitre-corbeaux.com/search/zend
  • http://www.maitre-corbeaux.com/search/phpunit
  • http://www.maitre-corbeaux.com/search/management
• À utiliser tout ou partie du code source du projet pour vos propres besoins… N’hésitez pas à me faire savoir en quoi ce site vous aura été ou non utile.
• À observer, critiquer, repenser, un petit projet complet Zend Framework développé par un autre.
• Autre ?

Votre avis

Alors me direz-vous, pourquoi cet article ? Et bien maintenant que le site a « tourné » un peu il contient pas mal de contenu, et commence à pouvoir être utile aux personnes en recherche d’articles sur des sujets orientés vers le développement Web, alors autant le faire connaître un peu.

Aussi, et surtout, je serais assez content d’avoir des retours, négatifs ou positifs :

• Sur le concept, si c’est utile, à qui et pourquoi.
• Sur la qualité du code, des tests et les choix techniques, ce que vous auriez fait différemment.
• Si vous êtes intéressé sur quelques explications sur l’architecture logicielle du site, je pourrais écrire dessus sans soucis, faites-le savoir si c’est le cas.
• Sur ce que vous voulez

Bref, vos commentaires ici, sur Github, sur Twitter, bref où vous voulez, sont les bienvenus. Quelque chose vous serait utile dans l’absolu ? Demandez toujours, si c’est réalisable dans le temps dont je dispose, je pourrais le planifier.

Je n’ai moi-même franchis le cap que récemment, et le but de ce rapide billet est de vous fournir quelques ressources pour vous lancer, ou simplement compléter vos connaissances sur PHPUnit et les tests unitaires de façon plus générale.

Tout d’abord, les excellents Webinars de Michelangelo van Dam à ce sujet, dont voici les slides :

http://joind.in/3381

Cet e-book, gratuit et très intéressant pour se lancer :

http://giorgiosironi.blogspot.com/2009/12/practical-php-testing-is-here.html

Et bien entendu, la documentation de référence, que je vous conseille de lire en entier car c’est une des meilleures documentation qu’il m’ait été donné de lire :

http://www.phpunit.de/manual/3.6/en/index.html

Loin d’être une simple documentation de référence, c’est aussi un guide complet, qui explique pourquoi tester, et qui aborde même le Test Driven Development (TDD).

Pour conclure, même si les tests unitaires peuvent rebuter de prime abord (accroissement du coût de développement initial, impression de se sentir un peu “perdu”, remise en cause très forte de sa méthodologie de travail) les bénéfices se font sentir très vite.

Et pas uniquement au niveau des régressions : tester son code avant même de l’écrire, c’est l’occasion de prendre du recul et de repérer des erreurs de design : si je n’arrive pas à tester mon code, n’est-ce pas parcequ’il y a un couplage un peu trop fort entre ces deux classes ?

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

Bien entendu, cela n’est pas sans inconvénients :

• L’application Zend Framework n’étant plus du tout sollicitée, la validité du cache n’est pas testée avant affichage, ce qui signifie que le cache doit être vidé via une autre partie de l’application (cron job, vidage du cache lors de la modification du contenu…).
• Les pages très dynamiques peuvent être difficiles à mettre en cache, surtout si des fonctionnalités Ajax sont présentes (activer ou non le cache en fonction du contexte, ne pas servir le cache pour les requêtes POST…).
• Les fichiers de cache doivent être accessibles dans le docroot, ce qui rends délicat la mise en cache de contenu à accès restreint.

Pour ne rien arranger, la documentation à ce sujet est un peu légère : je n’ai par exemple pas trouvé de cas concret de mise en place, et c’est ce que je vais tenter de faire maintenant

Avant d’aller plus loin je tiens a donner un petit avertissement : ce billet tient plus d’une compilation d’informations au sujet du cache Static que d’un véritable tutoriel. Les informations ont été testées tant que possible, mais n’ont pas bénéficiées de multiples relectures ou de tests approfondis. L’intégralité du code a été testé avec le Zend Framework 1.11.1, et PHP 5.3.3.

Le backend de cache Static est prévu pour fonctionner conjointement avec le frontend Capture. Il utilise également un autre cache pour stocker des métadonnées sur les pages mises en cache, typiquement un cache Core avec un backend File.

Première chose, on va créer un projet vierge :
zf create project static-cache

Ensuite on va créer une action qui sera mise en cache :
zf create action Cached Index

Ensuite on va éditer le fichier de configuration pour désactiver le buffer de sortie du FrontController : c’est un pré-requis indispensable pour que le cache Static fonctionne.
resources.frontController.params.disableOutputBuffering = 1

Accessoirement vous pouvez préférer le faire directement dans le code :
$front->setParam('disableOutputBuffering', true);

Il nous faut également quelques directives Apache, afin d’indiquer au serveur de servir les pages mises en cache en priorité si elles existent. On part du principe que les pages mises en cache sont seront situées dans le dossier cached du docroot. Voici le contenu de mon .htaccess, vous pouvez aussi vous inspirer de celui de la documentation du backend static pour définir le votre :

Vous noterez que ce .htaccess ne gère que les pages d’extension html et, si il suffit pour notre exemple, il se montrera très insuffisant pour une véritable application. On remarquera aussi que le cache de la racine du site est géré alors que l’action index ne sera pas mise en cache dans notre exemple : en prévoyant le coup dés le début, on s’assure de la possibilité de le faire plus tard au besoin.

Maintenant que les bases sont posées, on va mettre un cache static sur l’action cached du contrôleur index. On va le faire de deux façons différentes : « from scratch » d’abord, pour mieux cerner le fonctionnement du frontend Capture, et ensuite en utilisant le Zend_Cache_Manager et l’action helper Cache.

Pour activer le cache nous allons remplir la méthode init de notre contrôleur comme suit :

On instancie d’abord un cache Core avec un backend File pour stocker les métadonnées des pages de cache. Dans notre cas j’ai choisis de stocker le cache dans un dossier /data/cache/. A noter également qu’il est nécessaire pour le bon fonctionnement du cache d’activer le paramètre automatic_serialization.

Une fois que nous avons notre tagCache, nous allons instancier le cache Static : le frontend ne prends aucun paramètre particulier, tandis que le backend attends au moins deux paramètres : le dossier dans lequel stocker les fichiers de cache qui doit être publique (d’où le nom du paramètre : public_dir), ainsi que le cache Core pour les métadonnées (tag_cache).

Ensuite on s’assure de lancer le cache uniquement sur les actions désirées : dans notre cas uniquement l’action cached. On peut ainsi facilement mettre en cache d’autres actions en remplaçant la variable $actions :
$actions = array('index', 'cached');

La méthode start attends 3 paramètres dont 1 optionnel : l’id unique du cache, un tableau de tags à lui associer (pour faciliter la maintenance plus tard), et éventuellement une extension a donner au fichier de cache (par défaut ce sera .html). L’id unique est généré en récupérant l’équivalent hexadécimal de l’uri courante, je me suis sur ce point inspiré du code de l’action helper Cache (voir plus bas).

Vous pouvez lancer l’application et vérifier : l’appel de l’url /index/cached va générer le fichier html /public/cached/index/cached.html

Si le serveur est bien configuré, c’est ce fichier qui sera servit aux visiteurs, et non plus l’application.

Bien, maintenant on a vu comment mettre en place le cache Static « from scratch », il est donc temps de voir comment on peut aller beaucoup plus vite…

Car le Zend Framework offre deux aides précieuses :
* Le Cache Manager, qui permet de configurer vos caches depuis un fichier de configuration et de les récupérer facilement n’importe où dans votre application.
* L’Action Helper Cache dont le rôle semble dédié au cache Static. Je dis bien semble car en l’absence de documentation et / ou de commentaires explicites, c’est l’interprétation que je fais de son code source.

Le Cache Manager préconfigure un cache Static et son cache de métadonnées sous les clés ‘page’ (Zend_Cache_Manager::PAGECACHE) et ‘pagetag’ (Zend_Cache_Manager:PAGETAGCACHE).

Nous allons donc configurer ces caches depuis notre application.ini :

Et maintenant, nous allons remplacer le code de la méthode init pour utiliser l’action helper Cache :

L’helper Cache accepte deux autres arguments optionnels : un tableau de tags, et une extension.

Comme vous pouvez le constater, au final le déploiement de ce cache se fait très simplement, mais une recherche préalable est nécessaire pour bien appréhender les différents éléments qui entrent en jeu. J’espère que ce billet aidera quelques développeurs à s’y retrouver
Si vous avez des questions, ou des remarques, ne vous privez pas !

Ayant commencé à étudier le problème (en trois mois, il était temps ), j’ai en premier lieu avancé sur la problématique côté client : avoir un rendu des erreurs Mootools identique aux erreurs Zend_Form.

Vu la lourdeur qu’implique la modification des Zend_Form_Decorator pour chaque élément, j’ai pris le partis de minimiser ces modifications en adaptant tant que possible le CSS pour avoir la présentation souhaitée. Cette façon de faire convient pour la majorité des formulaires, ça serait dommage de s’en priver… Sur cette base, je souhaite donc que les validateurs Mootools produisent les même erreurs que mes Zend_Form.

Le fonctionnement du Form.Validator de Mootools est simple : on active la validation pour un formulaire, en affinant le comportement avec quelques options, et l’outil détermine les contrôles à effectuer en fonction des classes sur vos champs input : pas de liaison forte entre le client et le serveur, on se contente d’attribuer des classes.

Par exemple, prenons ce formulaire :

Notre champ input a deux classes assez particulière, minLength:3 et maxLength:20, qui vont permettre de vérifier côté client si le champ contient bien un texte entre 3 et 20 caractères.

Pour activer la validation, c’est simple, il suffit d’instancier Form.Validator :

Dés à présent, les validateurs seront sollicités sur les évènements onBlur (des champs input) et onSubmit (du formulaire).

Le Form.Validator de Mootools ne se charge « que » d’activer les validateurs et de stocker leur résultat : des évènements sont déclenchés, et il faut les utiliser pour gérer notamment l’affichage des erreurs.

Une implémentation plus complète est disponible via Form.Validator.Inline : cette classe permet d’afficher chaque erreur dans un bloc div pour chaque champ concerné. Pour l’utiliser, il suffit simplement d’instancier Form.Validator.Inline au lieu de Form.Validator :

Pour les intéressés, vous trouverez la documentation ici :

http://mootools.net/docs/more/Forms/Form.Validator

Et là :

http://mootools.net/docs/more/Forms/Form.Validator.Inline

En m’inspirant un peu du code source du Form.Validator.Inline, j’ai donc conçu une ébauche de Form.Validator.List. Cette classe permet d’afficher les erreurs sous forme de liste ul, exactement comme le Zend_Form_Decorator_Errors. De cette manière, je peux alterner contrôles côté client et côté serveur sans que l’affichage ne change pour l’utilisateur.

Je vous invite à jeter un oeil du côté du code sur le dépôt github :

http://github.com/lucascorbeaux/Form.Validator.List

Lorsque les travaux seront plus avancés et que le code sera mieux testé, je le déposerais sur la forge Mootools afin de toucher un plus large public. Pour ceux qui ne connaissent pas la forge mootools, on y trouve pas mal de plugins utiles et ça se trouve ici : http://mootools.net/forge/

Pour la petite histoire, il s’agit de ma première approche de github, et de la première fois que j’utilise git, n’ayant eut pour le moment que l’occasion de travailler sur SVN. Plus encore, il s’agit de ma première contribution, aussi modeste soit-elle… Ca fait longtemps que je voulais franchir le cap, c’est désormais chose faite ! Plus que jamais, tout commentaire, positif ou négatif, est plus que le bienvenue.

Petite update pour signaler la mise en ligne du plugin sur la forge Mootools : http://mootools.net/forge/p/form_validator_list

Il ne s’agit pas ici d’apprendre comment créer ses propres contextes. Pour ça je vous renvoie à cette adresse qui s’acquittera de cette tâche beaucoup mieux que je ne saurais le faire : http://framework.zend.com/manual/en/zend.controller.actionhelpers.html#zend.controller.actionhelpers.contextswitch

Ce dont nous allons parler aujourd’hui, c’est d’un piège dans lequel il est très facile de tomber lorsque l’on utilise un contexte « maison » pour la première fois.

Vous l’avez sentis venir, faîtes chauffer Zend_Tool car on va créer une nouvelle application. Par manque évident d’imagination, notre application se contentera d’afficher la date et l’heure dans une unique action datetime.

Voici notre contrôleur :

Notre vue, datetime.phtml :
Nous sommes le : <b><?php echo $this->escape($this->datetime); ?></b>

Vous m’en voudrez si on saute les explications ? Non ? Continuons, alors. Nous avons pour besoin d’afficher notre vue d’une autre façon, simplement sous forme de texte brut. Les deux contextes fournis par défaut par le Zend Framework étant xml et json, nous allons avoir besoin d’un contexte txt.

Nous rajoutons une méthode init à notre contrôleur :

Rien de très compliqué, on créé un contexte texte avec pour suffixe txt, un content-type défini à text/plain, on associe ce contexte à l’action datetime et on initialise le ContextSwitch.

On créé la vue associée, datetime.txt.phtml :
Nous sommes le : <?php echo $this->escape($this->datetime); ?>

Notre application fonctionne correctement, mais il y a deux problèmes :

• Le premier soucis, c’est que notre nouveau contexte, txt, est un contexte qui sera tôt ou tard utile ailleurs : il aurait plus sa place quelque part où on pourrait le réutiliser. Admettons que vous êtes sûr à 100% que votre contexte est totalement unique, et laissons en l’état.
• Le second soucis est plus sournois, nous allons l’illustrer.

Mettons que nous ayons pour besoin que la vue index nous redirige vers l’action datetime. Il suffit de l’implémenter de cette manière :

Si on appelle notre application via http://myapp/index/datetime, aucun soucis. Si on appelle notre application via http://myapp/, c’est le drame, une exception est levée :

Message: Cannot add context « txt »; already exists

La raison est simple : en utilisant forward, la boucle de dispatch instancie à nouveau le contrôleur et déclenche un second appel de la méthode init. Le contexte est donc créé deux fois ce qui provoque une exception.

Si notre contexte était si unique, nous aurions pu créer le contexte directement dans la méthode datetime me direz-vous ? Et vous auriez raison, le peu de temps avant que la direction ne vous demande une méthode date et une méthode time qui utilise le même contexte…

Nous allons résoudre le problème autrement, et définir le contexte une bonne fois pour toute, accessible dans toute notre application. De cette manière, il sera réutilisable ailleurs, et même exploitable en dehors de ce projet si nécessaire.

La première chose à faire est de retirer l’ajout de contexte de la méthode init :

Ensuite, il faut configurer notre ActionHelper en amont. Après m’être penché un peu sur le sujet, je pense que le plus simple et efficace consiste à utiliser le Bootstrap, par exemple en ajoutant une méthode _initContextSwitch :

Vous êtes libres de configurer à votre guise l’ActionHelper soit directement dans la méthode du Bootstrap, soit un utilisant des paramètres passés dans le fichier de configuration, créer une ressource pour Zend_Application…

La seule chose que je ne recommanderais pas serait de créer une classe héritant de Zend_Application_ContextSwitch : si vous voulez vous faire votre avis, allez jeter un oeil sur le constructeur et la méthode init de cet ActionHelper : il est assez délicat de modifier son comportement sans casser son fonctionnement exact, du moins sans réécriture massive du code.

Je suis bien entendu ouvert à tout avis, critiques, questions et retours d’expérience à ce sujet !

Le code a été écrit et testé avec le Zend Framework dans sa version 1.10.5.

L’idée était, sur le papier, très sexy :

• Conception d’une classe Javascript de vérification réellement réutilisable, sans retoucher le code pour chaque formulaire.
• Uniformisation du contrôle client et serveur : si les spécifications du formulaire change, il suffit de modifier notre Zend_Form et tout le reste suis.

Seulement voilà, le projet était à petit budget, et si le volume d’utilisateur était faiblard, le mutualisé l’hébergeant l’était plus encore : s’ensuivait des freeze à chaque validation de formulaire, qui m’a complètement freiné dans l’utilisation sur le onblur des éléments au lieu du submit du form, ce qui faisait perdre une grosse partie de la réactivité (la validation client-side attendait sagement qu’on valide le formulaire pour se faire, ce qui était d’un intérêt discutable…).

Conclusion : c’était un bonheur à programmer, et une horreur à utiliser.

Depuis les besoins ont fait que je me suis « contenté » de formulaire à l’ancienne, avec une validation server-side only. Ayant eut beaucoup d’application métier à développer ça n’a pas choqué grand monde : les utilisateurs étaient contents, c’était carré, ça fonctionnait, c’était fluide. Mais il faut l’avouer, ça n’était pas très sexy.

Ce screencast a fait germer l’idée de refaire un essai, plus ambitieux, plus carré, mais tout aussi évolutif et maintenable.

Mon objectif ? Trouver une façon simple mais robuste de lier les Zend_Form au Form.Validator de Mootools, de façon à offrir un contrôle homogène entre server-side et client-side, sans appel Ajax superflu : on réservera les appels Ajax aux besoins dont le serveur est indispensable, notamment vérifier l’unicité d’une valeur dans une table.

Je réfléchis à un plan d’attaque, et on se tient au courant

Prenons un exemple simple. Nous allons afficher quelques données en HTML, et nous voulons avoir un export XML des même données. Dans le cadre d’une utilisation au sein d’un formulaire dynamique, nous génèrerons ces données sous forme d’une liste select dans l’éventualité d’un appel Ajax.

Voici le code de notre controller :

Et voici nos vues :

Et voici le retour que l’on aurait pour chacune de ces vues :

Inutile de préciser que ce n’était pas trop le résultat attendu… Essayons maintenant de comprendre pourquoi. Si il vient assez rapidement de sentir un problème de conflit entre ContextSwitch et AjaxContext, quelques séances de debugging permettent de mettre le doigt sur le coeur du problème.

La première chose, est qu’en désactivant ContextSwitch notre contexte Ajax fonctionne parfaitement, cela nous conforte donc dans la théorie du conflit entre les deux helpers. Ensuite en regardant le cheminement de notre application lors d’une séance de debug, l’on se rends compte que l’helper ContextSwitch se déclenche en premier à la détection du paramètre format. Par conséquent, il lève une exception car il ne connaît pas le format html.

A ma connaissance, il n’existe pas de manière de modifier ce comportement, et même si il m’aurait paru plus logique qu’en présence d’une requête Ajax l’helper AjaxContext prenne le dessus sur le ContextSwitch, je me plais à croire qu’il y a une raison valable à tout ça. A ce sujet, si quelqu’un bout dispose d’un élément de réponse, je suis preneur

La solution la plus simple que j’ai trouvé pour ce problème est la suivante : modifier le paramètre devant définir le format, ce qui se fait simplement avec la méthode setContextParam(). Voici comment nous initialisons notre AjaxContext maintenant :

Désormais, plus de conflit, il suffit de spécifier /Ajax/html dans l’url de notre requête Ajax et tout marchera correctement. En espérant que ça dépanne quelqu’un qui un jour se serait retrouvé confronté au problème

Cet article n’a pas but de vous convaincre de quoi que ce soit, je vous expose juste une « façon de faire » qui jusqu’ici m’a plutôt bien réussi sur des projets de taille modérée. Il parle de concepts propres à Zend Framework 1.8 et ultérieurs : namespaces, application, ressources…
Si vous n’êtes pas familier avec ceci, je vous conseille de jeter un oeil ici : http://framework.zend.com/manual/en/zend.application.html
Et pour les namespaces de l’autoloader, c’est ici : http://framework.zend.com/manual/en/zend.loader.autoloader.html

La première chose consiste à créer ses bibliothèques personnelles, qui serviront pour le projet courant, et pour les projets à venir. J’utilise systématiquement deux namespaces pour chaque projet : le namespace de l’entreprise, et celui du projet en question. Cela permet de cloisonner les problématiques communes des besoins réellement spécifiques. Dans les exemples qui suivent, on considérera que le namespace d’entreprise est MyCompany et le namespace du projet MyProject.

Personnellement je dérive systématiquement les classes Zend_Db_Table (ainsi que les Row et Rowset) et la classe Zend_Controller_Action, même quand je n’ai rien à y mettre pour le moment. De cette manière, si jamais un traitement générique devait être décidé plus tard (par exemple passer à la vue un id Google Analytics) il serait encore possible de manoeuvrer sans remettre en cause tout notre projet. De la même manière, si on veut implémenter un algorithme maison de vérification des données avant toute sauvegarde, on sera bien content que toutes nos tables soient des classes filles de notre dérivée de Zend_Db_Table.

Prenons par exemple l’IndexController, sa classe mère sera MyProject_Controller_Action, elle même fille de MyCompany_Controller_Action, fille de Zend_Controller_Action. Un peu lourd à mettre en place en début de projet, ça devient bénin par la suite et permet une grande souplesse… On pourrait même aller plus loin, et créer un contrôleur type par module du projet si le besoin se faisait sentir.

Le reste de la bibliothèque sera beaucoup plus dépendant de vos besoins réels, mais quelques outils tels qu’un loader de formulaire ou de modèle pourrait grandement aider dans une majorité des cas… Une règle d’or toutefois : le but est bien de factoriser le maximum de code que l’on peut, mais il ne faut pas tomber dans l’excès. Certains cas par exemple semblent très facilement factorisable, mais leur évolution est quasiment impossible à prédire. Ca peut être le cas de la sauvegarde des données depuis un formulaire, ou toute demande ultérieure peut venir casser et / ou largement complexifier votre algorithme initial (qu’arrivera-t-il si on modifie l’interface pour diviser le formulaire en plusieurs pages, ou si on ajoute de nombreux éléments qui n’ont pas à être enregistrés mais qui influent sur le traitement…).

Enfin, pensez réutilisation : vous avez besoin d’une ressource supplémentaire dans votre bootstrap ? Même si celle-ci est propre au projet, tant que c’est possible privilégiez la création d’une classe de ressource plutôt que d’un élément de code « en dur » dans la classe de bootstrap. Comme ça, si le besoin s’avère plus général que prévu de prime abord, il sera toujours temps de la faire passer de MyProject vers MyCompany pour le prochain projet…

Un dernier conseil : le Zend Framework évolue vite. Aussi, si il est de bon ton de dériver les classes du Zend Framework pour leur greffer des traitements plus « personnels », faites attention à ne pas tout remettre en cause, ou vous risqueriez de passer pas mal de temps d’adaptation à la prochaine mise à jour majeure du Framework… Dans le même esprit, quand vous implémentez une ressource, un service, une conversion de mesure qui vous paraît très commune et qui pourtant est absente du Framework, n’en faites pas plus que le nécessaire. Il y a fort à parier qu’une version officielle sortira tôt ou tard, aussi contentez-vous du besoin du moment, il sera toujours temps d’utiliser la solution officielle quand elle existera. Prenons le cas de la ressource Log, sortis avec Zend Framework 1.10, et dont j’ai dû créer un ersatz cet été pour les besoins de deux projets : y passer plus longtemps pour prendre en compte plus de cas de figures aurait été inutile, vu que le manque est désormais comblé.

J’espère que ce bref article aidera quelques lecteurs à se représenter leurs futurs projets Zend Framework, ou au moins qu’il soulèvera quelques commentaires

N. B. : Après mûre réflexion, je ne suis pas totalement persuadé de l’indispensabilité du couteau pour la poule.