[Tutoriel] Moteur de template

[Ter Rowan]

en regardant le template, je me suis dit que c'était déjà proposé par les systèmes de template javascript (assez accessible, puisque j'arrive moi même à les utiliser alors que je n'arrive pas à rentrer dans les frameworks php)


après la question, (qui est aussi valable avec le XSL si ce n'est que XML plus verbeux que JSON pour un résultat identique) est de savoir a quel point il y a pertinence a calculer les pages côté serveur.

J'en vois au moins une : les moteurs de recherche.
Tout ce que j'ai lu sur les robots qui (crawl ?) les pages web montrent que le crawl se fait avant l'évaluation des données envoyées aux clients (donc on perd tout le contenu envoyé au template) L'intérêt de le faire côté serveur est au moins celui là : le moteur lit la donnée, pas le template

[Ter Rowan]

rien a voir avec l'objet, mais Xenos, j'ai vu sur ton blog que tu parlais de la méthode pomodoro, j'ai juste regardé dans wikipédia, vu que je ne connaissais pas.. Tu as un retour d'expérience bientot prévu dessus ?

a+

[niahoo]

• Une manipulation DOM possible (exemple: XPath)
• Une coloration syntaxique possible
• Une séparation des espaces de nom (pour mélanger des langages)
• Un traitement par XSL (oui, j'insiste lourdement :p mais je serai curieux de comparer les perfs d'un template XSL processé par libXSL natif, face à un template {{...}} processé en PHP)

Mouais, autant si on a un vrai besoin de performances ça me parle (même si en attendant je prefère un truc lent qui ne m'oblige pas à taper ... ça), autant pour le reste ça me parle pas vraiment :

La manipulation du DOM, vu qu'on créée de toute façon le rendu, on peut s'en passer : pourquoi parser les templates ? Si tu lis le DOM de tes templates pour en lire de l'information, c'est qu'il y a un problème d'architecture amha.

La coloration existe pour twig et blade, pour parler de ceux que je connais.

Pour afficher {{exemple}} sur blade c'est @{{exemple}}, sur twig il faut l'entourer :

Code :

{% verbatim %}
...
{% endverbatim %}

Pas terrible. Mais généralement ce sera plus simple d'appeler tes templates javascript depuis ceux en PHP en ne les faisant pas parser.

[Xenos]

J'vais pousser alors un cran plus loin: comment afficher @{{exemple}} ?
Pour la manipulation DOM, on peut passer de <p>Salut, <tpl:user_name/>!</p> à <p>Salut, {{user_name}}</p> (par un XSL par exemple ! ou par toute autre manip' DOM). L'inverse risque de ne pas être possible ou d'être délicat (passer de <li class="{{user_group}}'> à <li><xsl:attribute.../></li> sera ardu).

Pour pomodoro, okay, j'en tirerai un article asap

Tout ce que j'ai lu sur les robots qui (crawl ?) les pages web montrent que le crawl se fait avant l'évaluation des données envoyées aux clients (donc on perd tout le contenu envoyé au template) L'intérêt de le faire côté serveur est au moins celui là : le moteur lit la donnée, pas le template

Je n'ai rien compris à la phrase...

L'intérêt que je vois aux template, quels qu'ils soient, c'est de séparer les données du site (appelons-les le "coeur du site", puisqu'il s'agit de ce qui constitue vraiment la mécanique du site, ou du jeu web pour nous) de son rendu/moyen de diffusion (web).
Le serveur se compose alors en deux partie: une qui génère le XML du coeur de métier (mais bon, si on n'aime pas on fait un autre modèle de données), et une qui se charge de livrer ce que le client a demandé (du HTML? du JSON? du XML?). Le XSL rentre alors dans cette deuxième phase, qui peut se passer coté serveur (pratique si le client ne comprend pas le XSL, comme Google) ou coté client (pratique pour alléger la charge du serveur); alors qu'un template {{...}} nécessitera des lignes de code différentes coté serveur et coté client (pour du PHP en tous cas, peut-être peut-on utiliser les mêmes codes javascript sur des serveurs type Node.js?).

[Max72]

@Xenos : Tu peux utiliser n'importe quoi pour 'échapper' une variable. Soit l'entourer de balises comme Twig, ou mettre un truc devant (@ ou \ ou ce que tu veux).
Par exemple, avec des balises encadrantes {% NOPARSE %} ..... {% ENDNOPARSE %}, dans la continuité du code du tuto :

Dans la méthode parse() :

Code PHP :

<?php 

$this->content = preg_replace_callback("#\{\% ?NOPARSE ?\%\} ?([\s\S]*) ?\{\% ?ENDNOPARSE ?\%\}#", array($this, "_noparse_replacement"), $this->content); 

[Xenos]

• Faut-il échapper les "%" dans une regex PHP?! Je n'ai rien lu à ce sujet
• PHP possède le flag u (ungreedy), [\s\S] n'est donc pas requis (.* sera plus lisible)
• Applique l'OpenClosed principle, et remplace ta grosse fonction de parse() par un appel à un ensemble de parsers distincts, qui décorent ta classe:

Code PHP :

<?php 

interface IParser {

public function parse($contentToParse); /// @return string Parsed content

}



class ...

{

private $parsers = array();

public function addParser(IParser $parser) {

$this->parsers[] = $parser;

}



public function parse() {

$content = $this->content;

foreach ($this->parsers as $parser)

$content = $parser->parse($content);

return $content;

}

// ...

} 

[niahoo]

@@{{exemple}}. Je te laisse deviner comment on affiche ce même code. Où veux-tu en venir ?

Si le seul intérêt de parser le DOM de ses templates c'est de les convertir en une autre syntaxe de template, alors autant directement utiliser la seconde syntaxe de suite.

Ce que je comprends du post de Ter Rowan c'est que faire le rendu des templates côté client permettrait aux moteurs de recherche de n'avoir que de la donnée pure à indexer. Pas sûr que google indexe les API JSON, mais XML par contre oui, et pour le coup XSLT serait une réponse tout à fait adaptée.

[Max72]

En effet, il ne faut pas les échapper.
U (et non pas u) (Ungreedy) ne me sert pas ici car ce que je souhaite c'est prendre en compte les retours à la ligne. Je peux par contre utiliser #...(.*)...#s
Mais isU sera une meilleure alternative

Open Closed Principle : Je suis en plein dedans. Pour le moment, j'en suis à créer une interface pour mon système de cache. J'aimerai par la suite que ce système puisse laisser place à un système de cache autre que par les fichiers (libre choix à l'utilisateur de créer sa classe cache pour, par exemple, stocker le cache en DB).
Pas compliqué à créer, le plus long étant de réfléchir à un système évolutif mais restant simple.
D'ailleurs, je m'exerce avec ce moteur à appliquer le principe SOLID (pas avec le code du tuto ).

[Xenos]

J'en viens au fait qu'on doit gérer soit-même les échappements
Et oui, google indexe bien le XML mais il y aura des délicatesse pour gérer les poids des différentes données (google ne pourra pas donner le sens sémantique aux données, car la balise <titre/>, il ne la connait pas...)

[niahoo]

Tu veux dire que tu peux afficher

<tpl:user_name/>

sans gérer l'échappement ? Tu dois bien mettre CDATA machin ou autre truc non ?

Pour le sens sémantique en effet, mais ça sera pas pire qu'avec du HTML. Surtout qu'il y a probablement des set de balises que Google connait genre dublin core.