Discussion :

[vermine]

Avez-vous déjà manipulé de grands pans de HTML en JavaScript, et trouvé ça peu lisible et fastidieux ? Les templates sont là pour vous simplifier la vie et produire du code plus lisible et maintenable.

Cet article, de Sylvain Pollet-Villard, fait le tour des principales solutions de templating existantes en JavaScript pour vous permettre de trouver la bibliothèque qu'il vous faut.

N'hésitez pas à faire des commentaires sur son article !

Petit guide du templating client

[Angelsafrania]

AngularJs ne peut pas faire parti de la liste ?
C'est un petit framwork qui monte bien en se moment.

[edit] désoler j'ai un peu trop vite lu on dirait.

[SylvainPV]

"Petit" n'est pas la qualificatif le plus adéquat pour parler d'AngularJS

J'en parle section VII-A.

[NoSmoking]

Bonjour et merci Sylvain.

J'ai fini par lire ton article et le moins que l'on puisse dire c'est qu'il est limpide .
Peut être reverrais je mon approche de création d'éléments dynamiques si le besoin s'en fait réellement sentir, restera à trouver le templating le mieux adapté, il y a pléthore.

J'aurais un seul petit "reproche", il manquerait un lien vers PURE dans l'article.

[SylvainPV]

Merci NoSmoking, c'est corrigé.

Effectivement il y a beaucoup de choix et c'est plutôt une bonne chose. J'ai écrit cet article en voulant observer les avantages et inconvénients de chacun. Je compte m'en servir pour trouver le meilleur compromis possible et bosser sur ma propre librairie de templating. Mais ce n'est pas pour tout de suite

[NoSmoking]

je sais qu'une petite recherche est pas bien compliquée, d'ailleurs je suis directement tombé sur le lien ajouté, mais quand on a tout sous la main c'est mieux.

La multitude pose quand même un problème de choix judicieux.
Je connaissais déjà, partiellement, celui de John Resig, mais le dernier PURE me paraît digne d'intérêt, à voir et à tester à l'occasion.

[SylvainPV]

Oui PURE m'a intéressé aussi au premier abord, pour ses templates DOM-based et sa simplicité de binding entre classe et nom de variable (ce qu'ils appellent auto-rendering). En se servant des classes comme point de liaison entre modèle et vue, on met plus de proximité entre les données et le CSS associé à la présentation de ces données.

Le problème c'est que l'auto-rendering est très limité, par exemple on ne peut pas toucher aux attributs HTML. C'est pour ça qu'il y a les directives. Seulement les directives se trouvent du côté JS et non du côté HTML. Ce n'est vraiment pas pratique pour lire rapidement un template, il faut le HTML et le JS ouverts côté à côte pour bien comprendre le résultat. D'ailleurs tous les exemples du site utilisent des scripts inline précisément à cause de cet inconvénient...

[Kaamo]

Excellent article. Je croyais avoir mis un commentaire mais je me rend compte qu'il n'est pas là, je n'avais pas dû envoyer

Tu ne travaillais pas sur la création d'une solution de templating DOM-based logic less ?

[SylvainPV]

En effet, je bosse sur ma propre solution. J'en parle rapidement section VI. J'en suis encore au stade des spécifications, mais je dois mettre ce projet de côté jusqu'à février car j'ai un contrat sur l'écriture d'un bouquin.

[tchvil]

Salut Sylvain,

C'est l'explication la plus claire et précise que j'ai lu sur PURE en français.

Pour ton info, la première version était avec des data-xyz dans l'HTML.
Mais je voulais un HTML vraiment vide de logique.
Et aussi, avoir la possibilité d'associer des fonctions javascript anonymes.

Les directives sont donc arrivés avec le lien entre un selecteur CSS et sa logique(boucle, string ou fonction).

Le lien automatique entre class et le JSON est venu plus tard, pour rendre la librairie plus accessible. Mais aujourd'hui je le regrette. Ce n'est pas net, et fort limité.

-Mic

[SylvainPV]

Salut Mic,

C'est un plaisir d'avoir un commentaire d'un des auteurs de PURE sur mon article. Pour ceux qui se poseraient la question, Mic est CTO et co-fondateur de BeeBole.

L'auto-binding est un sujet intéressant, à explorer davantage. Ce que j'apprécie beaucoup avec ce système, c'est que cela force à ajouter des classes pour désigner les données, ce qui permet de rendre plus lisibles les surcharges CSS propres aux éléments correspondant à une certaine donnée :

Code css :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
.prenom { text-transform: capitalize; }
.nom { text-transform: uppercase; }

Une des limitations que j'avais sur PURE était qu'on ne pouvait pas mélanger auto-rendering et rendering via directives au sein d'un même template. Ce qui fait qu'un template conçu en auto-rendering doit parfois être réécrit avec une directive lorsque l'on veut rajouter un lien sur un attribut, par exemple.

J'avais imaginé pour ma solution un mélange des deux options de cette façon :

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

<span data-bind="prenom">

attribut data-bind vide = auto rendering selon ID ou classe

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

<span class="prenom" data-bind>

Mais ça ne colle pas à l'optique de PURE "zéro logique dans le HTML". Pour ma part un attribut à rajouter dans le HTML ne me dérange pas, ça donne un aperçu rapide à la lecture du template de quels éléments ont un lien et quels éléments n'en ont pas. Et ça réduit le risque de lien cassé ou indésirable, notamment quand le HTML peut être modifié par un tiers qui n'y connait rien (le designer de mon équipe par exemple )