Que pensez-vous de Talus' TPL ?

Hello,

Justement j'ai imposé ces normes pour qu'on puisse bien distinguer quand c'est un bloc, ou bien une variable... Mais après chacun fait ce qu'il veut :]

Oui, mais ça ne me gêne pas ;)

bon, faut que je fasse connaissance avec les filtres, et tout sera parfait :]

Maintenant que j'y pense, à propos du fait de devoir prendre le nom du bloc puis celui de la variable, dis toi qu'auparavant, il fallait mettre TOUS les blocs parents. Par exemple, il fallait mettre {grand_pere.pere.fils.MA_VAR}. Ca a été abrégé en {fils.MA_VAR}. :)

Enfin, dans une prochaine version (qui viendra... Je sais pas quand), pour l'attribut "name" de la balise <block>, il ne faudra plus spécifier le parent, comme suit :

Mais plutot comme ca :

Plus long à taper, certes, mais plus lisible et plus compréhensible. :)

Talus' TPL, j'adore. D'ailleurs j'adore mais j'suis une feignasse, et j'ai envie que Talus TPL se mette à jour tout seul =D . Pour ça je saurais le coder, le seul truc qui me faudrait, c'est un fichier qui m'indique la dernière version et où la télécharger, si tu pouvais me faire ça, ce serait parfait ^^

Mmh, je peux tenter de mettre un fichier .txt à disposition avec la dernière version. Ou même carrément un XML pour faire un changelog, ce pourrait être marrant...

Et pour le truc de la dernière version, j'ai un lien symbolique en attente sur le serveur, qui pointe direct vers la dernière version. :)

Je peux en savoir plus sur ce lien symbolique ? ^^

Si tu télécharges le package "cur", en gros, bah ca t'amene en fait sur la version courante (à savoir la 1.5.1) pour l'instant.

Le problème, c'est que pour le moment, c'est pas encore au point, donc je le garde au chaud pour plus tard...

On peut pas l'utiliser alors =/

Pour le moment, non. En fait, c'est juste à des fins de stats que je veux pas le laisser à l'utilisation (ca casserait tout §§). Faut que je refasse un peu le systeme de DL :)

Ok ^^ . Préviens moi quand il sera utilisable =)

Ce qui serait sympa, ce serait de pouvoir accéder aux superglobales sans déclarer des variables dans le code métier au préalable.

Je pense pas que ce soit si nécessaire que ça... Vu qu'en général, avant d'afficher de telles informations dans la vue, on fait souvent des transformations dans le code métier (échappements, vérifications, etc.)...

Si tu veux tout de même les avoir, il te suffirait d'ajouter cette regex avant celle des variables (dans talus_tpl_compiler.php) :

Ca devrait le faire...

(Même si je suis pas très fan d'ajouter la _GLOBALS, ca risquerait de dévoiler une faille critiquer (ou presque) pour le code métier : c'est une des raisons pourquoi je ne me mettrais pas ces deux regex par défaut)

Autre question : pourquoi tant de haine envers les conditions imbriquées ? Je veux dire que c'est impossible de mettre un <if ...> dans un autre <if ...> je sais que y'a une solution avec <elseif ... /> mais ça devient parfois illisible !

Edit : Après vérification ça marche très bien, désolé du dérangement, simple erreur de ma part =D

@Talus > On peut utiliser des filtres après ;)

Ouais mais non trop relou, il faut mieux faire tout ça du coté métier et non pas du coté de la vue. Les filtres, c'est bien gentil, mais vaut mieux faire attention.

preg_replace_callback ...

C'est bien plus compliqué que ça... Basiquement, j'ai une méthode pour appliquer des filtres sur une variable, et sur une variable normale. Et ca me fait chier de faire un autre callback qui, basiquement, ferait la même chose. Surtout que je me suis donné un mal de chien pour faire fonctionner le tout correctement ; C'est facile de voir le script, mais moins de le concevoir...

Et après, comme je l'ai dit, non, je ne mettrais pas ces variables par défaut dans le moteur TPL, pour des raisons de sécurité évidentes. C'est à l'utilisateur de faire apsser sa variable (quitte à la filtrer par derrière)... Autant pour les constantes, les variables basiques, je comprends, mais là non. Et je ne reviendrais pas sur ma décision ; au pire, y'a les regex postées plus haut si vous voulez les intégrer, à vos risques et périls.

Absolument: jamais je n'utiliserais les variables comme ça (au moins un array_map ...) dans mon TPL ! C'est la plus grosse porte ouverte aux failles ...

Salut, explorant les sources de la version 1.7.0, tu as fais une petite erreur de frappe dans Talus_TPL.php à la ligne 491 (ognore à la place de ignore).
C'est tout :D

En effet, et c'est à la ligne 498 :p

491 pour moi! Ca dépend des éditeurs ou autre :D
Sinon je suis depuis longtemps ton système de Template et j'avoue que c'est pas mal et que ça s'est pas amélioré au niveau des différentes versions (l'optimisation du code).
Talus_TPL propose énormément d'options certes un peu compliqué pour les débutants, mais suffisante pour les autres plus expérimentés :D

Ouais mais j'essaye de faire la base par défaut, surtout avec la dernière sortie ;)

Enfin, je suis toujours ouvert aux suggestions... Parfois on dirait que je râle (hein Nami :p), mais je le fais (souvent, mais des fois non) ;)

D'ailleurs, y'a des fonctionnalités "hors doc" dans la dernière release ^^

Bah, c'est vrai, tu râles ;o) !

Par contre, toutes mes suggestions ont été acceptées (sauf les filtres exotiques, mais ça c'était - juste un peu :p - useless XD).

Ca l'était complétement, oui...

(Han je viens de voir l'inline éditor - ça roxx de trop §§)

je reviens sur la possibilité de changer les < > en ce qu'on veut ("<%" "%>" §§), et {} en ce qu'on veut ("<%=" "%>" §§), enfin c'est pas obligatoire mais pour moi qui ai mon IDE en mode raccourci ça m'aiderait à ma productivité :).

Ouais ca j'y pensais aussi : genre <%s> </%s>, <% %s %> <% end%s %>, etc, etc...

Mais ca va polluer les regex par contre. Faut que j'optimise toussa :)

oui c'est le principal défaut ^^". Les regex vont devenir horrible, owi ! (sprintf §)

sprintf ou pas sprintf, c'est pas la la question...

je pense que ça serait encore plus imbuvable sans sprintf. Des regexs de plusieurs lignes, mmh <3.

Ouais mais ce sera aussi imbuvable avec les sprintf...

Bah, dans tous les cas ça sera imbuvable. à toi de voir si tu préfères avoir la regex en concaténation sur deux lignes ou une regex avec plein de %s sur une ligne.