Le web d'aujourd'hui est beaucoup axé sur des bases d'Ajax, couplés à de nombreux principes tels que KISS, DRY et le design pattern MVC (les principaux).
Maintenant, j'ignore vous, mais appliquer ces différents principes au maximum ouvre les portes de nouvelles complexités, là ou il devrait y avoir de la simplicité.
En effet, en règle générale, je suis confronté à deux principaux problèmes. Je vais vous les exposer ici et proposer une approche dans leur résolution.
Je vous invite à me donner votre avis et votre méthode, afin de parvenir à quelque chose de plus fonctionnel et me sortir de ce casse tête :)
Les moteurs de templates, il en existe beaucoup, notamment en PHP. A vrai dire, PHP lui même est un moteur de template à la base, c'est pour dire !
On peux classifier les moteurs de templates en deux catégories, en fonction du travail effectué : coté client et coté serveur.
Les moteurs de templates côté serveur
La liste est plutôt longue si on veux lister les moteurs de templates, ne serait-ce qu'en PHP. Le mieux est donc d'aller voir la doc de Wikipedia sur les moteurs de templates (en) pour profiter de la liste.
Parmis cette liste, on peux indiquer :
- Smarty : Quand même une référence, même si ce n'est pas mon préféré
- TinyButStrong : Le principal concurrent de Smarty
- H20 : L'implémentation du moteur de template de Django en PHP
- Twig : Similaire au moteur de template de Django
Les moteurs de templates côté client
Il existe peu de moteur de template étant traité côté client en ma connaissance. Leur avantage est de diminuer la consommation cpu du côté serveur. Le gros désavantage est les problèmes de compatibilités lié au différents navigateurs (non c'est pas vrai, je ne pense pas à un navigateur en particulier ! :p)
- Transformations XSL : Le serveur fournis un XML structuré et indique une feuille de style qui fera la transformation du XML en HTML. Son gros avantages et qu'il permet de transformer le XML en plein de format possible (PDF, DOC, etc). Le problème est que la transformation n'est possible que par les navigateurs récents.
- Les templates javascript, tel que JQuery Template ou PURE. Nécéssite l'activation de javascript et ne fonctionne pas pour toutes les pages (il faut au moins une page html qui contienne la structure principale).
Le problème actuel
Le problème actuel est que, pour répondre à une requête, il existe aujourd'hui plusieurs moyens :
- La réponse HTML
- La réponse JSON (pour du js)
- La réponse en XML (pour les webservices)
- ...
L'idée ici est de produire du code côté serveur qui ne se soucie pas du type de réponse. La réponse doit être formulée en fonction du type de demande.
En effet, que le client demande la liste des produits via son navigateur web, via une requête ajax ou via un webservice, le traitement effectué par le serveur sera le même
Seul la réponse change.
Une solution ?
Le but serait donc de proposer une interface de communication uniformisée qui prendrait en entrée le résultat du travail demandé (par exemple la liste des produits) pour la retourner dans le format attendu par la demande, peu importe cette demande.
Concrètement, cela serait possible via l'utilisation d'un wrapper autour de la couche de réponse du framework côté serveur. Au lieu de retourner la réponse tel que :
echo $oTemplate->render ();
vous faites un :
echo new ResponseWrapper ($oTemplate->render ());
par exemple.
Ensuite, il ne resterait plus qu'à mettre en place différentes classes par type de sortie que l'on veux. Cela pousse le vice à pouvoir proposer une réponse en .doc ou .pdf sans avoir à modifier (ou très légèrement) le code métier !
XSLT est un début de cette approche.
L'idée d'un tel moteur de template est excellente, mais pas encore totalement au point.
Entre autres, IE interprète des balises à sa façon et la compréhension de la structure d'un élément xsl est assez ... tordue :p
De plus, outre des possibilités de formatage au niveau des sorties (html, pdf, doc), la réponse est quand même limitée : le format nécéssaire en entrée DOIT ÊTRE de l'XML.
Donc à moins d'anticiper son travail en webservice et de faire tourner tous son code autour (notamment l'interprétation du xml par le javascript), l'utilisation du XML en tant que réponse limite quand même le type de réponse (et javascript préfère quand même le json ;)).
(En plus le traitement du xml avec PHP via DOMDocument est assez longue et nécéssite beaucoup d'instance :p)
Conclusion
Voilà, c'était mon point de vue sur la chose, quel est le vôtre ? qu'en pensez-vous ? comment faites-vous ? Je serai ravis de le savoir :)
