On y trouve du code tout prêt pour s'occuper de l'identification, de la génération de documents pdf, de la génération de formulaires et de leur validation, etc. Ainsi que la prise en charge de l'architecture MVC.

l'architecture MVC

Laissez de coté, pendant quelques mois, un programme qui compte quelques milliers de lignes de code. Puis revenez-y pour y faire une petite modification. Si vous avez développé votre programme un peu à la rache, vous avez toutes les chances de passer plus de temps à chercher l'endroit où vous devez faire la modification qu'à faire la modification elle-même. L'idée, avec le modèle MVC, c'est de s'organiser un peu. Pour le "M", vous commencez par regrouper le code qui accède aux données (au Modèle). Le "V", c'est la partie du code qui s'occupe du dialogue avec l'utilisateur (les Vues). Et le code qui décrit le comportement du programme, c'est le Contrôleur. Du coup, quand vous avez une modification à faire, ça aide à la localiser. ça aide aussi quand plusieurs développeurs collaborent sur un même projet.

MVC en pratique

MVC, donc, c'est bien. Mais encore faut'il trouver une façon de développer qui cadre avec le shéma. On peut par exemple organiser les différentes parties du code dans des dossiers. Là où ça devient plus délicat, c'est quand il s'agit de trouver une méthode pour mettre tous ces bouts de code en relation. Et c'est là qu'intervient la librairie MVC du framework Zend. Vous disposez alors d'une structure de base paramétrable. Indiquez-lui le dossier de vos vues, celui de vos contrôleurs etc, et le framework se charge de rendre tout ça cohérent.

Vous vous retrouvez alors avec une sorte de tableau de bord pour piloter votre programme. Abaissez tel levier pour passer en mode "Maintenance". Le bouton, là, c'est pour activer le mode "Débug". Mais s'il vous prend l'envie de rendre le tout pilotable par commandes vocales, le framework ne vous fournis pas les librairies. A vrai dire, ce n'est pas nécessaire: ces librairies existent déjà. Par contre, le framework vous aura bien déblayé le terrain pour les faire fonctionner avec votre application.

Quelques bémols

Difficile toutefois, quand on "extrait une brique suffisement générique", de ne pas se retrouver à y coller du code "pour le cas où...". Si bien qu'une fois intégré dans un programme donné, on a des chances de se retrouver avec une partie du traitement qui ne sert jamais. Et plus embétant, le code peut entrer en conflit avec le reste du programme. Par exemple, pour router le programme sur la bonne action, le framework Zend utilise l'url rewriting. Si votre programme réécrit aussi les URL, il vous faudra composer avec des règles qui vont bien pour le framework...

Une bonne idée consiste alors à paramétrer un minimum le tout pour éviter les traitements inutiles et accorder les parties entre elles. Mais le tableau de bord est vaste. Et pour certains ajustements, il vous faudra dévisser le capot...

En conclusion

On retrouve un peu ici ce qu'on peut voir du coté de Java EE. Un ensemble d'approches qui donnent un bon contrôle du code. Attention tout de même à ne pas foncer bille en tête sur son utilisation. On a vite fait de se retrouver avec l'équivalent d'un tank pour écraser un moustique. Disons que tout dépend du moustique... Comptez un minimum de temps pour l'apprentissage.