hello, je me suis mal fait comprendre pour l'histoire des moteurs de recherche :
dans la situation :
le serveur produit une page html avec template js (genre angular) et alimente ce template par de la données (genre json, en ajax, ou en include direct dans la page, etc...)
pour l'utilisateur c'est propre : affichage initial correct, se rafraichit rapidement, ...
pour le développeur c'est bien : bande passante réduite, séparation des données et de la vue, ...
pour le moteur de recherche, c'est la loose : il ne lit pas les données il lit uniquement la page avec le template js
si mavariable = "mon mot clef qui sert au référencement"
alors l'utilisateur verra affiché "mon mot clef qui sert au référencement"
et le moteur de template verra {{mavariable}}
pas glop
(ex j ai pris le premier de la recherche google, c'est pas le plus pertinent je trouve
http://blog.octo.com/seo-spa-angular/ )
Non, je parlais uniquement de ne pas gérer l'échappement dans le moteur de template si tu réutilises la syntaxe XML (car l'échappement est déjà géré par ce qui parse le XML). Dans les deux cas, il faut taper la séquence échappée dans le template.
Et ouep, du coup, je suis d'accord avec la remarque de Ter Rowan: une template JVS obligera à faire pointer l'URI sur le template lui-même, qui chargera les données, alors qu'XSL permet de faire pointer l'URI sur le document XML contenant les données, et c'est ce document qui va appeler le template. Effectivement, ainsi, le moteur de recherche index la page des données au lieu de la page de template.
ben c'est pas moi qui implémente le moteur de template ... dans les deux cas faut gérer l'échappement soi-même donc c'est la même chose. sauf que c'est un simple caractère pour blade ...
On peut très bien faire les 2..
Si tu echappes 1 seule variable ça va, si tu as un bloc de plusieurs lignes ( genre pour montrer un code source) alors la technique du @{{var}} devient plus lourde que des balises encadrantes.
Oui, ça ne change rien, XML n'apporte rien de mieux dans ces cas là.
J'ai commencé à implémenter le mien :
https://github.com/Zest-Engined/ZestTpl
Faut que je commente et documente un peu, de plus je n'ai implémenté qu'un seul parser (les variables).
Si quelqu'un veut en savoir un peu plus, j'expliquerai volontiers
Sinon le principe est simple : On créé un objet Tpl, et via cet instance on va pouvoir gérer et configurer le cache, assigner des variables etc
La classe Tpl ne fait que gérer les classes qui gravitent autour.
Le cache est modifiable (par défaut écriture dans un fichier), mais on peut très bien passer un objet Cache qui écrit en BDD ou autre.
Il est prévu d'implémenter un système pour implémenter automatiquement des parsers persos et des tags, et de le rendre aussi extensible que possible.
\{\{ ?(.*) ?\}\} sera peut-être une regex trop large, surtout avec le drapeau
s (DOT_ALL).
Attention à ce genre de fonction niveau injection:
Code PHP :
<?php
public function write($filename, $content)
{
$filename = $this->cache_dir . $filename . $this->cache_suffix;
file_put_contents( $filename, $content);
}
Si
$filename provient de l'extérieur, tu donnes accès à tout le système de fichier (ou presque). Note que même s'il ne vient pas de l'extérieur, la lecture du code actuel ne permet pas de s'en assurer, en d'autres mots, même si la variable
$filename est sécurisée ailleurs, elle ne l'est pas ici, et donc il arrivera un jour où l'injection aura lieu (pas sûr que je sois bien clair).
Pareil pour l'autre méthode de cette même classe.
Manque les getter/setter à cette FileCache. Note que l'héritage est moins souple que la composition.
C'est une bonne chose que d'avoir tout mis dans un namespace principal
N'oublie pas de commenter tout ça pour que ce soit réellement utilisable sur le long terme.
Attention à la licence GPL, qui peut-être trop raide pour certains cas (de mémoire, le code source d'une appli utilisant du code GPL doit être aussi GPL "ou presque").
J'ai pas regardé la logique de fond du code, mais ça semble pas mal sinon
J'ai toujours un peu de mal avec les
eval() en revanche...
[edit] le ob_start() dans le constructeur du Viewer me semble mal venu: il va créer des effets de bord indésirable. Le constructeur devrait avoir seulement la charge de créer l'objet, pas celle de faire des traitements annexes. Le ob_start() (précédé d'un ob_clean?!) serait mieux placé dans la méthode display().