[PHP5] LIGHTEMPLATE - MOTEUR DE TEMPLATES ULTRA-LÉGER

Commentaire de codefalse le 14/04/2008 10:01:21 administrateur CS

Franchement intéressant comme script, j'ai juste une petite question :p
J'avais commencé à m'en faire un et j'ai arreté quand je me suis rendu compte d'un truc :
Comment est-ce que tu fait si par exemple je veux avoir une ligne sur deux de telle couleur et une autre d'une autre couleur ? afin d'alterner ?

Je regarde encore et jte met une note :)

Commentaire de codefalse le 14/04/2008 10:19:36 administrateur CS

en js pourquoi pas en effet, ensuite le css3 pour ma part je ne trouve pas que c'est à l'ordre du jour. pas que je suis contre en effet, jusque que trop de gens utilisent encore des navigateurs qui ne sont pas tous compatible css3 :p

En fait pour voir ce qui manquait à mon code, j'ai regardé du coté de TinyButStrong, leur exemple en ligne te montre plein de fonctionnalités que tu peux implémenter. Je ne peux que te conseiller d'y jeter un coup d'oeil :)

En tout cas ca mérite un 9/10 :)

Commentaire de neigedhiver le 14/04/2008 11:28:31

Salut,

Merci pour ton commentaire.

J'ai eu du mal à comprendre l'intérêt de ce que tu me proposes, mais ça commence à venir (j'ai l'esprit un peu embrumé là).
En fait, à l'origine, les arguments $aSearch et $aReplace, sont là pour permettre de parser des boucles, c'est à dire en écrasant les variables du template (plus exactement, en ne les utilisant pas, au profit de variables spécifiques au template de la boucle).
Je ne m'étais pas posé la question de l'utilisation en dehors de ce contexte.
Dans l'absolu, tu as raison : $aSearch et $aReplace peuvent ne pas être des tableaux... Mais est-ce vraiment un problème si la fonction n'accepte que des tableaux ? Est-ce que c'est tellement plus compliqué pour le développeur de passer des tableaux plutôt que des chaines de caractères ? (quitte à ce que ce soit le développeur qui utilise le transtypage pour passer ses chaines en argument).
Parce que du coup, la faille dans le code que tu proposes, c'est que si $aSearch est un objet ou un nombre et que $bMerge est à false, alors str_replace risque de faire la tronche.
D'où la nécessité de vérifier dans le premier if le type des variables $aSearch et $aReplace.

Mais ça me fait réfléchir à l'intérêt qu'il peut y avoir à ce que $aSearch et $aReplace puissent être également des chaines.

Commentaire de putch le 14/04/2008 15:25:34

exellente classe !

"l'inclusion de fichiers : que nenni => on peut récupérer un fichier parsé dans une variable et l'assigner à une variable de template"

ouai ok mais la méthode SMARTY est bien pratique aussi ^^

sinon dans ton exemple ligne 23
$news = LighTemplate -> fetch('no_news.html');

manque le $ devant LighTemplate :)

++

Commentaire de Morphinof le 14/04/2008 15:37:22

Justement je trouvais que pour remplacer une seule variable du template c'était plus simple d'envoyer juste une chaine qu'un tableau avec un seul élément comme sa même pas besoin de transtyper puisque la fonction le ferais d'elle même ^^
Je me suis peu être mal exprimé :p
C'est pour sa que je mettais a voir si c'est mieu ou non ^^

Commentaire de neigedhiver le 14/04/2008 15:46:13

@Morphinof  : Oui, bon, certes, c'est plus simple d'envoyer une chaine plutôt que de la transtyper. J'avoue. Mais je ne suis pas opposé à le permettre. Simplement, pas avec ton code qui laisse passer tout et n'importe quoi, y compris les variables de type int ou object... Et ça, c'est pas glop.

Commentaire de neigedhiver le 14/04/2008 15:58:06

Moui. Et transtyper par défaut... pffffffffff Ca va servir une fois sur un million, très sincèrement...
En fait, j'hésitais même à changer la visibilité de la méthode parse() pour la mettre en protected.
Mais bon, des fois qu'on ait envie de parser un contenu qu'on a récupéré autrement qu'avec fetch()...
Très sincèrement, je préfère que le développeur se prenne par la main et transtype quand il en a besoin plutôt que de faire un traitement systématique inutile dans 99% des cas...

Commentaire de malalam le 14/04/2008 19:19:24 administrateur CS

Hola,

bon, je vais faire du linéaire d'abord (enfin...en suivant quand même peu ou prou le déroulement de la classe). Et je préviens, je suis crevé (d'ailleurs, vais me faire couler un chtit expresso...).

- __construct() : moi, j'aurais d'abord testé si le répertoire templates passé en paramètre est un répertoire avant de faire le reste. C'est toujours ça de gagné si jamais ce n'est pas un répertoire valide.

- parse() : si tu comptes rester avec des tableaux en paramètre, autant typer tes paramètres : public function parse($sContents = '', array $aSearch, array $aReplace, $bMerge = false){}
Ca t'évite un contrôle et ça prévient le développeur qu'il s'est planté. Parce que là, si je passe une chaîne ou toute autre valeur scalaire,  il ne se passe rien de visible (le parsing se fera avec l'existant, sans tenir compte de ce que j'ai passé en paramètres).

- display() et displayLoop() : elles servent à quoi ? Enfin, pourquoi avoir surchargé deux méthodes existantes qui sont en plus publiques ?

- fetchLoop() : array_map() est très pratique et clair, mais bien plus lent qu'un foreach(). Donc si tu veux optimiser...;-) Tu peux toujours tester en bouclant plutôt qu'en utilisant ton array_map(). Sans compter que si tu transformais d'abord ton tableau en ArrayIterator, ce serait peut-être encore plus rapide.
Ah j'avais pas vu que tu ne le transformais pas en ArrayIterator. Tu attends qu'on te passe un objet implémentant Iterator, ou un tableau. Ben pourquoi tu ne castes pas directement, donc ? Comme ça tu ne jongles qu'avec un seul type.

- assign() : moi, si j'étais toi, j'ajouterais un paramètre (constante de classe) indiquant si on veut ou non écraser un éventuel ancien couple. Une erreur est vite arrivée : par défaut, on n'écrase pas, on prévient (ou l'inverse hein, mais bon...). Un peu comme la fonction extract().

Bon à part ça, c'est une très bonne classe, légère et agréable :-) Et facile à utiliser.

Commentaire de neigedhiver le 14/04/2008 19:32:43

Salut patron lol,

- __contruct() : Justement, je vérifie que le répertoire de template existe : c'est la fonction realpath qui le fait pour moi, c'est pour ça que je teste ensuite avec === false. J'utilise realpath parce que.... C'est peut-être idiot, remarque, c'est une habitude que j'ai de bosser avec des chemins absolus, par précaution. Je me suis donc pas creusé la cervelle : j'ai utilisé realpath, qui retourne false si le chemin/fichier n'existe pas.

- parse() : ah ben ouais... C'est carrément vrai, ça évite de faire un test...

- display() et displayLoop() : elles servent juste à afficher le résultat... C'est pas utile, mais ça bouffe pas spécialement de ressources et c'est plus lisible... à mon avis...
Cela dit, il faut bien avouer qu'elles ne font pas grand chose... Elles peuvent être supprimées... C'est vrai que si je force le dév à passer un array() à parse(), il peut aussi bien se mettre un echo sur le résultat de fetch()...
Vais les virer.

- fetchLoop() : ah ! array_map() est plus lent que foreach()... Merde alors ! Vais bencher, parce que dans mon esprit, il était évident que c'était plus rapide... Pas que je te crois pas, juste que j'aime bien vérifier avec mes noeils.

- assign() : très juste... Un petit paramètre en plus, ça ferait pas de mal. Une constante de classe, c'est vraiment nécessaire ? Un ptit booléen c'est pas suffisant ?

En tout cas merci pour tes commentaires. Je pensais pas avoir laissé passer tout ça !

Commentaire de neigedhiver le 14/04/2008 20:00:48

Bon alors je viens de bencher. Désolé Patron, mais ta cote de popularité vient de baisser dans les sondages...

Si j'exécute une fois un foreach() et une fois array_map(), la différence est insignifiante (de l'ordre 0,00002 sec) :

Foreach : 0.000134944915771
Array Map : 0.000115156173706

Si je les mets dans une boucle for pour 5000 itérations, array_map éclate litéralement foreach() :

Foreach : 0.673834085464
Array Map : 0.615473031998

En réalité, parfois foreach() est plus rapide, parfois c'est array_map(). C'est très aléatoire. J'en déduis que c'est kiff-kiff les deux... Donc je vais garder mon array_map(), hein, si tu veux bien ;)


Pour rebondir sur ta réponse à Codefalse :
"Mais rien n'empêche de prévoir un petit ajout à la classe permettant de déclarer une alternance sur une variable particulière"

En réalité, rien n'empêche personne de modifier la classe comme il l'entend (GPLv3), ou de l'étendre pour ses besoins. Après tout, un développeur sait aussi adapter du code à ses besoins, surtout quand c'est aussi "simple" que cette classe (en comparaison avec des packags comme Smarty ou PEAR) ^^

Commentaire de malalam le 14/04/2008 20:17:55 administrateur CS

chuis quand même étonné, j'ai refait un tout petit test sur 1000 itérations :
<?php
$a = range(0, 1000);
/*
function add($v) {
return ++$v;
}
*/
$iStart = microtime(true);
foreach($a as $i => $v) {
$a[$i] = ++$v;
}
//$a = array_map('add', $a);
echo microtime(true) - $iStart;
?>

je suis en moyenne à 0,008 avec le foreach, et à 0,010 avec le array_map() moi.

Commentaire de malalam le 14/04/2008 20:25:34 administrateur CS

Là sous Windows XP, et au taf sous Une distrib Debian. Même combat lol.
T'as benché quoi et comment ? Ton code ?

Commentaire de neigedhiver le 14/04/2008 20:36:13

Bon alors sur mon dédié, c'est pas le même résultat mdr

Array_map() est carrément plus lent :-(

100000 iterations
Foreach : 6.09541702271
Array Map : 7.51797103882

Mince alors... Mon pc est une vraie daube !!
Comme quoi... C'est vraiment urgent que je trouve du boulot... Ca peut plus durer... Firefox et Amarok en même temps => quanta qui rame... :/

Conclusion : je vais p'têt' mettre un foreach, hein... T'as gagné...

Commentaire de malalam le 14/04/2008 20:40:20 administrateur CS

"P.S. : tu vois, c'est exactement ce genre de discussion que j'imagine, quand je te parlais de débats... Mais pas uniquement, hein... Juste pour illustrer..."
Puis
"Conclusion : je vais p'têt' mettre un foreach, hein... T'as gagné..."

Ouais, moi aussi, c'est le genre de discussions que j'aime : quand je gagne ;-) Chuis d'accord, faudra que ce soit tout pareil!!

Commentaire de neigedhiver le 14/04/2008 20:48:10

Ah tiens, c'est pas con ça... Du coup, t'aurais pas eu l'idée de dire dans un même message quelle version tu as, toi...

Moi, je suis avec PHP 5.2.3
et mon dédié est en 5.1.4 (putain, vais p'têt' penser à faire une mise à jour...)


"Ouais, moi aussi, c'est le genre de discussions que j'aime : quand je gagne ;-) Chuis d'accord, faudra que ce soit tout pareil!!"
PTDR

Ben voyons !! Surtout que si c'est la version de PHP, pour le coup, on aurait raison tous les deux lol

Commentaire de garfield90 le 14/04/2008 21:14:18

juste quelques petits trucs en passant :

- Tu ne vérifies pas l'existance de la clé dans clearVar(), ca risque de poser quelques soucis si la clé n'existe pas :'(
- Que ce passe t'il si tu incorpore plusieurs templates avec des variables identiques ? ( a moins que ce soit gerer au moment de l'incorporation).

Tout ca pour dire que les moteurs de templates se suivent mais ne se ressemble pas.(cf le mien : http://www.phpcs.com/codes/MOTEUR-TEMPLATE-PHP5_45263.aspx, un petit peu de pub ne fait pas de mal, d'autant plus qu'il n'est pas/peu commenter)

Commentaire de garfield90 le 14/04/2008 21:35:49

ok,

pour le unset, je savais pas, je dormirai moins *** ce soir :P (ah, cette habitude de tout vouloir checker)

concernant le 2eme point, tu dois donc t'amuser a redéfinir pour chaque template un pattern pour ta variable (pas tres pratique comme truc), mais (peut etre|surement) moins gourmand que d'instancier un autre template.

Commentaire de neigedhiver le 14/04/2008 22:36:03

@Codefalse : Ben perso, je préfère laisser aux développeurs qui le souhaitent le soin d'étendre cette classe pour en faire ce qu'ils veulent. Pour l'alternance des couleurs, par exemple, si l'idée de Malalam est loin d'être mauvaise, c'est encore le genre de truc qui va servir une fois tous les 107 ans.
A moins que...
Vais y réfléchir quand même... Soit une méthode spécifique pour gérer une alternance quelconque (simplement, comme le suggérais Malalam, un tableau de remplacement que le développeur et le designer utilisent comme bon leur semble) lors d'une itération...
Bon, ben ce sera pour la prochaine version alors... Après le cache... (chaque chose en son temps, hein).

@Garfiled : T'as raison de vouloir checker... Moi aussi, j'ai tendance à le faire. Mais je cherche toujours (oui, oui, toujours toujours) si un test peut être évité malgré tout (en faisant les opérations dans un certain ordre par exemple, en faisant attention aux valeurs de retour et aux erreurs levées, etc).
Tiens par exemple, une petit optimisation que j'ai faite pour la version 0.3 : je récupère le contenu d'un fichier avec @file_get_contents. Si le retour est false, alors seulement je cherche pourquoi ça a échoué, au lieu de vérifier avant que le fichier existe et est accessible en lecture. Les erreurs, c'est ce qui se passe, normalement, le moins souvent...

Sinon, je donnais cet exemple là, mais bon, c'est un exemple à la con. Effectivement, c'est moins lourd que d'instancier un nouvel objet. Mais c'est pas forcément plus facile de s'y retrouver dans ses templates si de l'un à l'autre le format des variables change...
C'est pour ça que ton message m'a fait m'interroger sur la possibilité de passer, comme pour fetchLoop(), un tableau de valeurs spécifiques pour un template, avec la possibilité de mélanger ou non avec les variables globales. Et plus j'y pense, plus je me dis que c'est indispensable...

Donc, mise à jour très prochaine, avec :
- foreach() au lieu de array_map()
- type hinting qui économisera des tests
- possibilité de passer des variables locales.
- correction de la méthode assign() selon les conseils de Malalam
- euh ça fait déjà pas mal...

Puis faudra que j'y mette du cache...

Commentaire de garfield90 le 14/04/2008 23:32:30

ouaip, concernant les erreurs je suis pas tellement d'accord avec toi :
- le @ est chronophage  (enfin un peu, le @ est juste bon pour les email ou pour délimiter les patterns regex :P)
- si tu testes les erreurs après c'est que tu en as eu, ce qui n'est pas normal :D (enfin, c'est mon humble avis), le fait de tester avant évite justement de l'avoir.
- quand tu parles d'un systeme de cache, c'est une couche supplemtaire, pas une fonctionnalité supplémentaire?

Je pense pas qu'un moteur de template est a gerer du cache :
soit ta donnée est valide et tu associe la donnée en cache a ton template
soit tu génère tes données caché et tu associe la donnée en cache a ton template

ton cache est externalisé a ton systeme de template, de plus ca te permet de le factorisé pour pouvoir l'utilisé pour autre chose (cache SQL, cache JSON, ... )

Commentaire de neigedhiver le 15/04/2008 01:17:03

Bon les enfants, vous avez vu l'heure ? J'espère que vous êtes couchés, là maintenant.

@Garfield : (si ton pseudo n'est pas complet, au moins, ça fait pas d'erreur)... Euh bon sérieusement...
Je suis partiellement d'accord avec toi, pour la gestion des erreurs. Seulement, parfois, au lieu de tester avant si ça va passer, on peut présumer que ça va passer, et voir ensuite pourquoi ça a chié.
Je suis d'accord, c'est pas la meilleure solution. Pour moi, le plus important concernant les erreurs, c'est de les gérer. Là, il s'agit d'une classe qui a vocation à être utilisée par des développeurs. Elle ne traite aucune information saisie par un internaute. Le développeur est supposé faire en sorte que dans son code, il n'ait pas d'erreur. Seulement, ça peut toujours arriver...
Il a copié ses fichiers sur un nouveau serveur, et les permissions ne sont pas gérées de la même manière, le fichier de template n'est plus accessible en lecture par le serveur : c'est une erreur qui n'est pas censée arriver. Si le développeur fait son boulot correctement, il cherche des fichiers qui existent, il ne les supprime pas, etc.
Maintenant, c'est pas une méthode que je préconise dans tous les cas. Pour le traitement de données qui proviennent de $_POST ou $_GET, je dis pas : il faut forcément vérifier avant. Mais parfois, je pense qu'on peut se permettre quelques libertés. Dans ce cadre là, ça ne me choque pas vraiment. On évite 2 tests de fichiers avant de lire le contenu.

Pour le cache, ton point de vue est tout à fait pertinent. Tellement pertinent, qu'il va me falloir discuter de ça avec mon chef/collègue (patron, t'es dans l'coin ?).
Du coup, la mise en cache de HTML peut être intéressante pour, par exemple, des boucles : une liste d'articles qui ne change pas souvent, la liste des membres, etc. Parser à chaque fois alors que le contenu est rigoureusement identique, ça me parait lourd et inutile. Mettre le contenu du template de cette liste en cache ne me parait pas absurde : même si le contenu est mis en cache, si on peut éviter de faire 200 remplacements de variables avant d'afficher, c'est toujours ça de gagné, surtout si le site a pas mal de hits.

Bref, ça se discute...
En tout cas, je pensais pas que ma source provoquerait autant de commentaires. Mais c'est intéressant tout ça. Merci à tous les participants :)