Moteur de template

[niahoo]

Mais par exemple, avant de se lancer dans la création d'un moteur de templates, ce que je ferait (mais ce n'est que mon humble avis), c'est que je prendrais les trois moteurs de templates les plus utilisés du marché ; je les étudierai pour comprendre leur système de parsing et de compilation ; et j'en listerai les avantages et les inconvénients.

Là on aurait un article super intéressant pour ceux qui se demandent comment ça fonctionne, et ça permettrait en plus de mieux choisir en sachant les forces et les faiblesses de chaque moteur. (Bon sauf que ce genre de papier existe déjà)

Ensuite, je chercherais une nouvelle approche qui n'aurait pas encore été expérimentée, et j'essaierai de prouver pourquoi elle est mauvaise. Puis une autre approche, etc. Et quand j'en aurai une que je n'arriverais pas à trouver mauvaise, j'implémenterai rapidement un prototype, car on aurait là une vraie alternative.

[Akira777]

Un que j'aime bien quand je suis hors-framework (ce qui n'arrive plus trop dernièrement) j'aime beaucoup pour sa simplicité RainTPL : https://github.com/rainphp/raintpl3
Il est vraiment KISS.

Pour les plus gros projets, c'est Twig ou Blade pour Laravel.

Ceci dit, ci-template (https://github.com/philsturgeon/codeigniter-template) pour CodeIgniter fais le taff. Theme/Layout/Partials et Views. On charge une vue ou on build un layout. Pas d'extension particulière et pas de tag, on reste sur du <?= $is_connected; ?>.

[niahoo]

C'est ce que j'aime bien dans Blade aussi, si vraiment tu as besoin de créer une donnée, ou bien de définir une lambda pour une loop, tu es quand même dans un fichier PHP donc c'est possible. (les {{ }} ne sont que des raccourcis pour <?= ?>)

[Xenos]

@niahoo
Ah, j'ai retrouvé l'adresse du site que j'avais eu l'occasion de faire lors d'un stage:

http://eclerd.fr/ECN/site-perso/

C'est un site pur XML/XSL (sources incluses, "Télécharger le pattern", en bas). Je n'y ai pas implémenté le système "si l'utilisateur ne prend pas XSL en compte, je l'exécute coté serveur".
Un élément intéressant est de voir que le XML des données de la page est transféré à chaque fois (léger), alors que les XSL ne sont transférés qu'une seule fois (le cache du navigateur s'en charge ensuite): cela allège le réseau.
Pour un forum, le gain ne doit pas être énorme (les données changent beaucoup entre deux pages), mais sur un jeu web, le gain peut être important (la quantité de données est faible: on manipule surtout des nombres).


J'ai également DevianTools qui marche ainsi: le code PHP génère un DOMDocument, et suivant si l'utilisateur prends XSL en charge, le site envoie ou bien le XML de ce DOMDocument (et le navigateur applique le template XSL), ou bien le XSL est exécuté coté serveur et le client reçoit un HTML.


Servi en HTML par défaut


Un test permet de savoir si le client prend XSL en charge (iframe vers un doc XML+XSL témoin)


Un cookie enregistre le résultat du test


A partir de maintenant, comme le serveur reçoit le cookie indiquant que le test est passé, il sert du XML au lieu du HTMl et le navigateur fait la transformation.

[Aedius]

tant qu'a parler des moteurs de templates coté client, on peut partir sur de l'angular JS.

https://angularjs.org/

L’intérêt étant alors de pouvoir alléger le trafic comme dans la solution de Xenos, mais en plus, gérer les modifications dynamique des données javascript.

[Sephi-Chan]

Angular ou Backbone (je recommande Marionette, qui améliore considérablement Backbone), React (de Facebook, qui a le vent en poupe en ce moment), Ember, Knockout, etc.

A ce jour je conseillerais plus React que Angular, qui est en train de passer en V2 et dont la V1 ne sera pas rétrocompatible.

[niahoo]

Ok Xenos merci des infos.


Aaaaah React, que c'est bon ce truc. On y retrouve toute l'intelligence de d3js* mais en plus sur un DOM virtualisé donc extrêmement rapide, et en ayant plus de liberté sur l'association data/DomElements (BOn en même temps d3 c'est plus pour faire du svg que du HTML même si ça fonctionne très bien !

* Le pattern fonctionel données -> render() -> DOM au lieu de manipuler du DOM

[Max72]

@niahoo : Non, on ne réfléchit pas pareil
Par grosses librairies j'entends les scripts qui s'étendent sur une arborescence non-nécessaire (un moteur de templates avec 168 fichiers et 15 dossiers O_o ), qui ont des fonctions qui ne (me) servent pas, qui sont souvent complexes à utiliser et adapter..
Sinon l'approche que j'ai a sûrement déjà été utilisée (peut-être par Twig ou autres, pas regardé ), et je n'y ai pas encore trouvé de faiblesse (rapide, léger, flexible). Peut-être les trouverez-vous

@Akira : J'ai été voirRain, et ce que je souhaite faire s'en rapproche beaucoup. Il est simple et évolutif.
Par contre en regardant le code, j'ai l'impression que le cache stocke aussi les valeurs des variables. Est-ce cela ?
Si oui pas génial pour un site dynamique, surtout un jeu où les ressources bougent énormément.

[Xenos]

Je trouve l'argument du "15 dossiers, 168 fichiers" mal venu. WAMP, c'est 4200 fichiers, 449 dossiers: donc il faut pas du tout l'utiliser (les sources PHP, c'est 17.000 fichiers d'ailleurs)?
L'un des buts de l'OO et de la plupart (si ce n'est tous) des langages informatiques est de masquer la complexité par une interface simple. D'accord, le moteur de template fait peut-être des milliers de trucs qui ne te servent pas, mais rien n'oblige à tout utiliser / lire toute la doc.

Je pense que ce genre de raisonnement, basé sur le nombre de fichiers, de lignes ou autre stats du genre, vient d'une mauvaise tendance des dev "solitaires" (je suis passé par cette même tendance): vouloir tout maitriser, tout contrôler dans leur projet, et refuser ainsi toute lib déjà faite.

Je trouve l'argument type "ce moteur de template déborde de son cadre et fait un système de cache qu'il n'a pas à faire" bien plus pertinent.

[Max72]

Bien que cela soit en ma défaveur, je suis tout à fait d'accord avec toi.
Seulement pour l'exemple de Wamp (que je n'utilise pas :p ), ce n'est pas la même chose, car je n'ai absolument pas les compétences pour créer une alternative. Je suis donc bien obligé d'utiliser un truc tout fait.

Imaginons le cas où tu utilises jQuery, mais uniquement pour faire des FadeIn. Pas compliqué à reproduire en JS pur. N'aurais-tu pas envie de créer une simple fonction ou 2 qui feront le même boulot, au lieu de charger une librairie complète ?