+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Tutoriel] Moteur de template (/showthread.php?tid=7324)
RE: [Tutoriel] Moteur de template - Ter Rowan - 23-02-2015
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
RE: [Tutoriel] Moteur de template - Ter Rowan - 23-02-2015
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+
RE: [Tutoriel] Moteur de template - niahoo - 23-02-2015
(23-02-2015, 07:26 PM)Xenos a écrit : • 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.
RE: [Tutoriel] Moteur de template - Xenos - 23-02-2015
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
Citation :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?).
RE: [Tutoriel] Moteur de template - Max72 - 23-02-2015
@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);
La méthode associée :
Code PHP :
<?php
private function _noparse_replacement($matches)
{
$str = $matches[1];
$str = str_replace("{", "& #123;", $str);
return str_replace("}", "& #125;", $str);
}
Comme on sait que chaque balise commence par un { et se termine par un }, il suffit de remplacer ces caractères par leurs équivalents HTML.
Mon template :
<body>
{% NOPARSE %}
{{titre}}
{%FOR:pays%}
<b>{{ nom }} </b><br/>
{%FOR:regions%}
{{nom }} a le numéro : {{numero}}<br/>
{%ENDFOR%}
{%ENDFOR%}
{% ENDNOPARSE %}
{%FOR:pays%}
<b>{{ nom}} </b><br/>
{%FOR:regions%}
{{nom }} a le numéro : {{numero}}<br/>
{%ENDFOR%}
{%ENDFOR%}
</body>Rendu :
Code :
{{titre}} {%FOR:pays%} {{ nom }}
{%FOR:regions%} {{nom }} a le numéro : {{numero}}
{%ENDFOR%} {%ENDFOR%} France
Nord a le numéro : 59
Oise a le numéro : 60
Belgique
Flamand a le numéro : Y'en a ?
Wallons a le numéro : Je sais pas..Edit : J'ai du insérer un espace entre & et#123 sinon le forum m'affichait une accolade, à supprimer en réel.
RE: [Tutoriel] Moteur de template - Xenos - 23-02-2015
• 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;
}
// ...
}
Du coup, tu pourras ajouter de nouveaux parsers à la volée, plutôt que d'éditer le code de la classe tout le temps:
Code PHP :
<?php
class varParser implements IParser {
public function parse($content) {
return preg_replace("~{{(\w+)}}~", "<?php echo \$this->data['$1']; ?>", $content);
}
}
class skipParser implements IParser {
public function parse($content) {
preg_replace_callback("#\{\% ?NOPARSE ?\%\} ?([\s\S]*) ?\{\% ?ENDNOPARSE ?\%\}#", array($this, "_noparse_replacement"), $content);
return $content;
}
private function _noparse_replacement($matches) {
$str = $matches[1];
$str = str_replace("{", "{", $str);
return str_replace("}", "}", $str);
}
}
$templateEngine = new ...();
$templateEngine->addParser(new skipParser());
$templateEngine->addParser(new varParser());
Oui, cela fait des classes en plus, mais on ne manage pas un projet informatique depuis son scope général (le projet entier) jusqu'au scope atomique (chaque ligne de code). On le manage comme un arbre: du scope N+1, tu ne t'intéresse qu'au scope N. Donc, qu'il y ai 100 classes de parsing ne pose aucun soucis. En revanche, avoir une seule classe qui contiendrait les 100 preg_*, là, ca va faire lourd à gérer !
Note qu'avec les deux approches, les parsers doivent s'exécuter dans l'ordre.
RE: [Tutoriel] Moteur de template - niahoo - 23-02-2015
@@{{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.
RE: [Tutoriel] Moteur de template - Max72 - 24-02-2015
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
).
RE: [Tutoriel] Moteur de template - Xenos - 24-02-2015
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...)
RE: [Tutoriel] Moteur de template - niahoo - 24-02-2015
Tu veux dire que tu peux afficher
<tpl:user_name/>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.