Proposition de nouvelle syntaxe

Bonjour,

TBS mon doux TBS.
TBS est je trouve très bien, mais sa syntaxe peut rebuter, mais elle permet des choses très sympathiques comparés aux autres systèmes de template.

Cependant la syntaxe de TBS fait que je n'arrive généralement pas à convaincre les gens de l'utiliser, il faut admettre qu'elle est spéciale, et que des choses standards tel que "ne pas afficher le block si", sont perturbantes à coder avec TBS.

J'ai découvert il y a peu PHPTAL, je retrouvais pas mal de TBS dans sa conception, et j'ai décidé de l'adopter, car je réussi beaucoup plus facilement à convertir les gens à celui-ci du fait de sa syntaxe bien plus clair, exemple :

<ul>
<li tal:repeat="book books" tal:content="book/title">titre du livre</li>
</ul>


Ce que j'apprécie ici, c'est par exemple ne pas noyer la boucle dans le contenu lui meme, car avec TBS ça donne :

<ul>
<li>[book.title;block=ul]</li>
</ul>

Ce qui perturbe en général, et ne contribue pas du tout à la lisibilité du template pour un programmer.

Particulièrement si j'affiche le ul seulement si j'ai des données dans le livre :

<ul>
<li>[book.title;block=ul;bmagnet=ul]</li>
</ul>

Lire le template devient très difficile, pour savoir que le ul n'est pas affiché si je n'ai pas de livre, je dois lire TOUT le code du ul pour voir le bmagnet. Je ne suis ici que dans un cas simple, ça peut sembler anodin, mais ça devient nettement moins anodin sur un vrai projet.

Avec PHPTAL ça donne :

<ul tal:condition="exists: books">
<li tal:repeat="book books" tal:content="book/title">titre du livre</li>
</ul>

C'est encore une fois beaucoup plus lisible.

Mais PHPTAL n'est pas parfait, certaines choses dans sa syntaxe sont bien moins lisibles, exemple :

<select name="target">
<option tal:repeat="repository repositories" tal:content="repository/name" tal:attributes="value repository/value; class repository/class">nom du repository</option>
</select>

Ce qui sous TBS donne :
<select name="target">
<option value="[repository.value;block=option]" class="[repository.class]">[repository.name]</option>

Il y a du bon des deux cotés donc, mais du parfait dans aucun des deux.
J'ai deux chois, soit demander à PHPTAL de changer des choses, soit à TBS. PHPTAL utilise une phylosophie bien à lui, et est une conversion de TAL sous Python, demander les changements qui m'intéressent ont beaucoup moins de chances de passer.

TBS n'est pas dans ce cas de figure, et puis fait pas un francais, c'est plus facile de communiquer ;)

Donc, je ne veux pas jeter l'ancienne syntaxe, mais en ajouter une nouvelle, et pourquoi pas à terme enlever l'ancienne, voici des idées de syntaxe,  jeté sans trop de réflexions :

<ul tbs="exists:book">
<li tbs="loop:book">[book.title]</li>
</ul>

et l'autre exemple :

<select name="target">
<option tbs="loop:repository" value="[repository.value]" class="[repository.class]">[repository.name]</option>
</select>


Oui vous l'aurez compris, je PHPTalize TBS ;)
Ça n'est peut-être pas la solution.

Cependant je reste intiment convaincu que TBS doit grandement évoluer au niveau de sa syntaxe pour être beaucoup plus lisible, et de ce fait beaucoup plus agréable à utiliser.

Salut Oxman,

Ton message est très intéressant, surtout que je me casse pas mal la tête aux sujet des syntaxes à adopter. Je n'ai toujours pas tranché comment résoudre la fonctionnalité de modif d'attribut prévue pour la version 4.

Mais je peux te répondre sur plusieurs points.

Pour rélaliser :
<ul tal:condition="exists: books">
<li tal:repeat="book books" tal:content="book/title">titre du livre</li>
</ul>

Avec TBS tu peux faire la solution simple que tu as écrite, mais ça marche aussi à la PHPTAL comme ça :
<ul [onshow;block=ul;when [book.#]!=0]>
<li>[book.title;block=ul;bmagnet=ul]</li>
</ul>

En fait tu peux mettre le [onshow] où tu veux entre <ul et </ul et ça marchera.
TBS propose la solution magnet par souci de simplicité mais ce n'est pas une obligation.


Un point important pour TBS c'est que les balises puissent être placées dans la partie visible du modèle. La syntaxe PHPTAL est pratique pour les codeurs qui touchent au coeur du HTML. Mais pour ceux qui veulent faire leur modèle HTML avec un outil visuel, PHPTAL devient une vraie galère puisqu'il se code dans les attributs. TBS peut faire les deux, on peut mettre ses balises un peu où on veut.

Il ne faut pas oublier qu'un développeur de HTML sur deux utilise des outils visuels. Mais le meilleur c'est que seul TBS est capable de faire des fusions de fichiers Open Office. Et cela grâce à sa technique. Avec la version 4, il pourra même faire les nouveaux documents Microsoft Office.
Avec PHPTAL, ou même d'autres moteur de modèle, tu ne pourras fusion un document Open Office que si tu dézipes le conteneur, et que tu retouche les XML à la minime, et au final ton modèle ne pourra plus s'ouvrir sous Open Office. C'est quand même bien plus simple de le faire directement depuis l'application, non ?

Mais en fin de compte tout est possible (ou presque) avec les plug-ins.
Pourquoi pas un plug-in TBS pour accepter la philosophie PHPTAL.

Ce qui est sur c'est qu'entre :
<ul [onshow;block=ul;when [book.#]!=0]>

Il faut que je lise attentivement, que je réfléchisse, et encore, ça n'est pas clair ce que ça fait.

Tandis que :
<ul tal:condition="exists: books">
C'est déjà beaucoup plus clair.

Alors après oui pourquoi pas :
<ul [exists:books]>

Mais ce qui m'embête dans ce code, c'est la résultante HTML :
<ul >

Et l'autre façon d'écrire :
<ul[exists:books]>
qui donne une résultante HTML correcte à mes yeux :
<ul>

Je ne trouve pas sexy de coller les balises, mais soit.

Je me doutais que tu allais me sortir une façon de mettre le exists dans le <ul avec TBS, je savais que c'était possible.

Ce que je veux avant tout, c'est arrêter avec les syntaxe abscons dans tous les sens.

Je pense que c'est bien plus un frein qu'autre chose.

Car si je résume, on doit utiliser :
<ul [onshow;block=ul;when [book.#]!=0]>
Tout ça parce que :
<ul [exists:book]>
n'existe pas.

On en revient à faire des hack en tout genre, où à être forcer à utiliser des notations complexes alors qu'elles pouvaient être bien plus simple.

Exemple ?

Dans la phylosophie de TBS on dirait plutôt :
<ul [exists:book;ul]>
Où quelque chose du genre.

Mais pourquoi imposer le ul alors que je suis dans le ul ?
Si je ne précise rien et bien par défaut je prend le tag où je suis.
Et c'est valable encore une fois pour toutes les balises de TBS :
<li>[book.title;block=li]</li>
Deviendrait :
<li>[book.title;block]</li>

block oui c'est bien c'est beau c'est bosch (:p)
mais pourquoi utiliser le mot clé block plutôt que "loop", "repeat", un mot beaucoup plus clair et transparent ?

Il faut revoir tout ça à mon sens.

2009 nous voilà :)
Je remonte un peu le sujet, tu n'avais pas répondu ;)

Salut, et bonne année,

> On en revient à faire des hack en tout genre, où à être forcer à utiliser
> des notations complexes alors qu'elles pouvaient être bien plus simple.

La syntaxe PHPTAL est plus simple, mais elle fait moins de chose.
TBS va bien plus loin. A fonctionnalité équivalente tu ne trouveras pas dans les sources existants plus simple que la syntaxe TBS.

Par exemple, si tu veux que ton moteur de modèle fusionne autre chose que des sources XML, alors il faut abandonner la syntaxe attribut de PHPTAL.

> Mais pourquoi imposer le ul alors que je suis dans le ul ?
> Si je ne précise rien et bien par défaut je prend le tag où je suis.

Ca peut se faire.

> mais pourquoi utiliser le mot clé block plutôt que "loop", "repeat",
> un mot beaucoup plus clair et transparent ?

Je suis assez d'accord, "block" c'est pas top. C'est par compatibilité continue que j'ai gardé ce terme. "loop" et "repeat" c'est pas top non plus car un "block" actuel peut aussi définir une section conditionnelle;


> Il faut revoir tout ça à mon sens.

J'essaie d'améliorer la syntaxe, et on peut tout revoir pour une version TBS 5, mais quand je planche concrètement sur ce que je veux que TBS fasse, j'ai du mal à trouver une autre syntaxe.

A trop vouloir le rendre générique et flexible, est-ce que l'on n'en devient pas trop compliqué ?

Je sais que c'est le but premier de TBS, mais quelle utilisation réelle de TBS est fait pour autre chose que du templating HTML ?

Si ça reste très marginale, peut-être est-il intéressant de se dire que TBS devrait prendre une nouvelle orientation et plus se spécialiser dans le templating HTML afin d'avoir une syntaxe bien plus intéressante.

salut,

> A trop vouloir le rendre générique et flexible, est-ce que l'on n'en devient pas trop compliqué ?

Oui, c'est souvent un dilemme.

>quelle utilisation réelle de TBS est fait pour autre chose que du templating HTML ?

Je connais au moins deux autres applications réelles autres que le HTML/XML : TBS fait du texte pour les emails et des documents OpenOffice (c'est du XML mais dont le code source n'est pas accessible).

> peut-être est-il intéressant de se dire que TBS devrait prendre une
> nouvelle orientation et plus se spécialiser dans le templating HTML

C'est une voie normale pour un moteur de template, mais cette voie est accessible par la réalisation de plugins. j'ai déjà un plugin "HTML" qui permet de simplifier la travaille des pages HTML. Ce plugin pourrait être enrichie en supportant la syntaxe que tu propose. C'est techniquement possible.

Coucou :)

Du chemin a été fait dans le sens de mon message depuis ?
J'ai l'impression que non.

Au sujet de cette discussion donc quand est-il, toujours pas de nouvelle syntaxe en vue ?

Salut,

Je ne connais pas bien PhpTal, mais accepterais-tu de bosser avec moi sur ton idée de la manière suivante :
1) étudier la faisabilité d'une moulinette qui traduise pour, un modèle donné, les syntaxes PhpTal en syntaxe TBS
2) implémenter cette solution sous forme d'un plug-in qui agirait lorsque qu'on charge un modèle ou un sous-modèle
?

L'idéal ne serait pas d'avoir une syntaxe PHPTal like.
Mais plutôt une syntaxe TBS new/light.

Mais que l'on parle de PHPTal like ou TBS new/light l'idée d'une surcouche ensuite traduite par un plugin en syntaxe TBS ne me semble pas la meilleure des façon.
Ca ne me semble pas bien propre :)

Je sais que l'on ne parle en soit que d'un pattern Adapter, mais bon pas très approprié ici je trouve.

Qu'est ce que tu entends par "syntaxe TBS new/light" ?

Quelques exemples, ancien, nouvelle syntase.
Ce ne sont que des propositions, avec une réfléxion légère, mais ça donnera un peu la tendance :

<td>[blk1.key;block=tr]</td>
<td>[tr loop blk1][blk1.key]</td>

<td colspan="4">[blk2;block=tr;nodata]There is no data. </td>
<td colspan="4">[tr show blk2 when nodata]There is no data. </td>

<h1>Exemple - [onshow.x]</h1>
<h1>Exemple - [show x]</h1>

<td>[onshow.name1;ope=max:10]</td>
<td>[show name1 format trunc:10: ]</td>

<td>[onshow..now;frm='yyyy-mm-dd']</td>
<td>[show @now format date:'yyyy-mm-dd']</td>

<td class="cell-1">Link: <a href="http://[onshow.url;magnet=a]">TBS Site</a></td>
<td class="cell-1">Link: <a href="http://[show url when empty delete a]">TBS Site</a></td>

<td class="cell-1"> Link: <a href="http://[onshow.url;magnet=a;mtype=m+m]" >TBS Site</a></td>
<td class="cell-1"> Link: <a href="http://[show url when empty delete a match m+m]" >TBS Site</a></td>

Etc, etc... :D

Même ce qui pourrait être encore plus sympa :
<td class="cell-1"> Link: <a href="http://[show url when empty delete <a> match <m>+</m>]" >TBS Site</a></td>

Voire encore :
<td class="cell-1"> Link: <a href="http://[show $url when empty delete <a> match <m>+</m>]" >TBS Site</a></td>

On devrait même plutôt mettre ça :
<h1>Exemple - [onshow.x]</h1>
<h1>Exemple - [x]</h1>

<td>[onshow.name1;ope=max:10]</td>
<td>[name1 format trunc:10 ]</td>

<td>[onshow..now;frm='yyyy-mm-dd']</td>
<td>[@now format date:'yyyy-mm-dd']</td>

Dans tes exemples, tu remplaces les séparateurs d'arguments ";" par des espaces. Mais cela pose problème pour les valeurs d'arguments ou des critères qui ont des espaces.
D'ailleurs ce n'est pas la philosophie de PhpTal. PhpTal adopte une syntaxe basée sur les arguments XML. Les paramètres des blocs et des champs sont des attributs de balises HTML/XML.

Je croyais avoir dit de mettre phptal un peu de côté ? lol
Et je ne propose pas que de remplacer ; par " " ;)
Quel valeur d'argument avec des espaces ou critères avec espace ?

> Quel valeur d'argument avec des espaces ou critères avec espace ?

Les deux.

Tu proposes plusieurs syntaxes mais j'ai l'impression que si on pousse leur formalisme on arrive a des complications dans le concret.
Par exemple :
[x] est trop commun dans un texte ou un code Javascript pour être une balise de template.

[@now] est une bonne idée mais en fait TBS a deux types de balises automatiques : [onshow..now] et [onload..x], voir même [var..x]
On m'a remonté plusieurs fois que cette notion est insaisissable pour les codeurs de templates purs. Je suis d'accord et je réfléchie à une amélioration, mais en attendant je dois distinguer les deux.

Les caractères < et > sont interdits dans la syntaxe TBS car ils cassent la structure XML/HTML.

Comment va se comporter ta balise si $url vaut 'empty' ?
Avec une telle syntaxe comment gères-tu les autres conditions tels que "if" ? 
Cette syntaxe est sympa à lire pour un petit nombre de paramètre, mais que cela donne-t-il si je veut ajouter un format date, plus une condition {si <0 alors affiche "erreur"} et que je veux déplacer cette valeur vers un attribut (paramètre att) ?

Alors il faut peut-être utiliser d'autres balises ? ;)
Ou alors [$x] ou [[$x]] ?

Oui trop de différences entre le onshow, onload etc, qui au final ne sert à rien (ça n'existe pas dans les autres système de template)
Ok pour le <> tu as raison, c'était une idée comme ça.

Donne un exemple complet TBS et je te donne la conversion.

Autre chose concernant [x] c'est parce que les balises de TBS sont très simple, sur les autres template on a des trucs du genre {% %} {{ }} [[ ]] [% %] etc.
Et quand on a les mêmes données dans du code Javascript par exemple on les échappes avec une séquence spécial genre :
[[ escape ]]
voici un [[ super ]] texte
[[ /escape ]]

>Donne un exemple complet TBS et je te donne la conversion.

<!-- [onload.cst.first_date;frm='dd/mm/yyyy(locale)';if [val]='na';then '(non renseigné)';if [val]='?';then '(inconnue)';magnet=span;mtype=m*;comm] -->

Donne moi aussi la balise <span> de ton exemple

<span>
première date :
<!-- [onload.cst.first_date;frm='dd/mm/yyyy(locale)';if [val]='na';then '(non renseigné)';if [val]='?';then '(inconnue)';magnet=span;mtype=m*;comm] -->
(selon nos informations)
</span>

<span>
première date :
<!-- ['(non renseigné)' if cst.first_date = 'na' ; comm ] -->
<!-- ['(inconnue)' if cst.first_date = '?' ; comm ] -->
<!-- [cst.first_date format date:'dd/mm/yyyy(locale)' if cst.first_date not in  ('na', '?') ; comm ] -->

(selon nos informations)
</span>

Mais pour moi un tel code n'a rien à faire dans un template, enfin pour moi et tout ceux qui aiment le pattern MVC.
Un tel bout de code devrait être dans un Helper et pas dans le template.

Et du coup on aurait un truc bien plus sexy :

<span>
première date :
<!-- [showFirstDate(cst.first_date) ; comm ] -->

(selon nos informations)
</span>

Il n'y a plus personne ? ^^

salut,

Si si, les jours passent trop vite.

> Mais pour moi un tel code n'a rien à faire dans un template, enfin pour moi et tout ceux qui aiment le pattern MVC.

Comme la plupart des autres moteurs, TBS n'est qu'une brique qui n'a pas vocation a structurer l'architecture de ta solution, mais juste à séparer les logiques du code et de la présentation. C'est à toi de implémenter comme tu l'entends. Les boucles, les conditions et le formatage sot les besoins basics de moteurs de template.

>Un tel bout de code devrait être dans un Helper et pas dans le template.
>Et du coup on aurait un truc bien plus sexy :

Si tu va par là, alors PHP est un moteur de template. Ceci est soutenu par certains, mais ce n'est pas mon avis. En tout cas ce n'est pas l'idée que je me fais d'un moteur de template.

En tout cas ça ne change rien à ma syntaxe.

Je vois un problème très embêtant à ta syntaxe : pour repérer les deux premières balises, le moteur doit rechercher dans le template toutes les occurrences de "['". Or ce bout de chaîne est très courant tant dans le JavaScript que dans le contenu, cela cause un problème de perf, d'autant plus que ta balise doit être lue ET analysée complètement pour vérifier sa syntaxe (pour TBS, une simple lecture suffit car les paramètres ont tous la même syntaxe, il seront analysés plus tard par pour la fusion).
En plus il me semble un simple JavaScript  "var f=document.forms['coucou']" ferait planter le moteur.

Si tu dois penser ta syntaxe par rapport au fonctionnement de ton moteur, il y a malus quelque part ;)
Tu dois déjà t'affranchir de toute contrainte technique quand tu penses ta syntaxe pour vraiment avoir une syntaxe super clean.

De plus concernant le [] qui match trop facilement dont on a déjà parlé, j'ai suggéré de faire comme les autres templates des balises un peu moins courante, genre {% %} genre [[ ]] genre [% %] enfin il y a beaucoup de choix.

De plus, sachant qu'un moteur de template doit compiler les templates pour avoir une rapidité exemplaire, la première analyse peut-être un poil plus longue, ça ne sera pas embêtant pour le fonctionnement nominale.

> Si tu dois penser ta syntaxe par rapport au fonctionnement de ton moteur, il y a malus quelque part ;)

Et pourtant, ce n'est pas si simple.
Si Smarty a une syntaxe qui fait tant penser à PHP, c'est parce qu'il est orienté compilation des modèles.
Si TBS a une syntaxe relative c'est pour réaliser des modèles naturels (TBS est le seul à avoir des mdoèles XHTML ou HTML qui sont W3C valides, et des modèles Ms Word éditables dans Word)
Si PHPTAL est orienté syntaxe XML c'est probablement pour être parsé ou pour attirer les codeurs de XML.

> Tu dois déjà t'affranchir de toute contrainte technique quand tu penses ta syntaxe pour vraiment avoir une syntaxe super clean.

Le paramètres "ope" de TBS ne sert à rien qu'à améliorer les perf (on écrit "ope=max:4" mais on aurait tout aussi bien pu avoir une syntaxe "maximum=4"). Ce paramètre offre un gain de perf de l'ordre de 30 à 50% sur al fusion d'un champ.

Oui, ça je suis d'accord pour ce que tu dis sur TBS, mais ce que je dis ne casse justement pas la compatibilité avec la validation des modèles XHTML/HTML.
Du moment que l'on utilise des balises à l'intérieur des balises HTML, des balises qui ne commencent pas par <>, et aucune balise en dehors des balises HTML on est compatible.

Et je maintiens que pour avoir des bonnes performances le mieux c'est d'avoir les modèles en cache.
Ca ne change pas le fait que la source est compatible W3C.

Et tu peux avoir une syntaxe bien plus clean sans rien perdre des avantages de TBS.
Comme je l'ai montré dans les messages plus haut.

Donc ? :)