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
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+
(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.
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?).
@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.
