Traqueur de bugs
Ville : Villeurbanne
Pays : France métropolitaine
Études : INSA Lyon
|
Hum, c'est pas faux en effet, il y a quelque chose qui ne va pas ici. 
|
CookieKiss !
Études : EPITA
|
Salut,
J'ai cherché un peu et j'ai pas vu d'équivalent de la boucle for.
Si je souhaite répéter l'affichage d'un élément un certains nombre de fois, comment puis-je faire ?
J'ai besoin de ce genre de chose pour afficher par exemple les numéros de page dans un système de pagination 
Edit: je peux peut-être essayer avec range() mais je trouve ça moche
|
Traqueur de bugs
Ville : Villeurbanne
Pays : France métropolitaine
Études : INSA Lyon
|
Tu peux t'en sortir avec une boucle foreach et range() en effet.  Je ne crois pas qu'il y ait de for, à confirmer.
|
People are strange
Ville : Paris
Pays : France métropolitaine
Études : EFREI
|
Sinon tu as toujours les blocs à disposition... Ou une structure foreach. Mais c'est au coté PHP qu'il faut renseigner l'array...
|
CookieKiss !
Études : EPITA
|
J'ai utilisé les blocks et du coup je fais un for du côté de php 
Sinon félicitations pour ton système
|
CookieKiss !
Études : EPITA
|
Encore un petit problème
Dans mon fichier template j'ai :
Code : XML | <foreach ary="{$tutorial_box.DATA['families']}">
...
</foreach>
|
et ça donne ça comme rendu :
Code : XML | <foreach ary="$__tplBlock['tutorial_box']['DATA']['families']">
...
<?php endforeach; ?>
|
tutorial_box est le nom du bloc dans lequel je me trouve et DATA est la variable associée à ce bloc (un tableau associatif).
Il semblerait que le parser a bien traduit ma variable en php mais pas le foreach qui va autour. Est-ce une erreur de ma part ?
Merci
|
People are strange
Ville : Paris
Pays : France métropolitaine
Études : EFREI
|
A priori c'est bien un bug du moteur.... As-tu essayé avec la 1.7.0 ?
(P.S > Essaye d'éviter de poster tes problèmes dans les commentaires du tuto, j'y passe pas souvent... Vois sur le forum que j'ai développé à cet effet )
|
Avis : Très bon
Ville : Avesnes-sur-helpe
Pays : France métropolitaine
|
Bravo à Talus pour son super moteur et bravo à Vincetn1870 pour le tutoriel si bien rédigé.Vous avez mes félicitations .
Je viens de comprendre comment fonctionne un moteur de templates, à quoi ça sert et surtout j'ai découvert le moteur de templates .
Quand mon site passera en Version 2 je le ferrais en OO et surtout avec ce super moteur de templates .
Cordialement robin.
|
Luxe, Calme, Volupté
|
J'étais un peu sceptique quant à l'utilité d'un système de tpl pour l'utiliser maintenant au quotidien ça aide quand même vachement bien et celui là est super léger.
|
Mouhahahahaha
Études : Université Libre de Bruxelles (ULB)
|
Ce système de template est vraiment pas mal du tout !
Bravo à l'auteur 
|
People are strange
Ville : Paris
Pays : France métropolitaine
Études : EFREI
|
Hello,
Je préfère le notifier ici, afin d'éviter certaines surprises : la version a été de nouveau mise à jour, du à un bug relativement critique concernant les foreach. Merci à minirop pour l'avoir découvert.
Les archives ont donc été mises à jour, ce sera transparent pour ceux qui téléchargent à partir de maintenant (plus ou moins). Les autres, pensez à retélécharger.
Merci
|
Yamo...
Études : ENSEA
|
Salut !
J'ai du mal à comprendre l'intérêt de tout ça.
Citation : TutoCe que nous allons voir ici consiste à remplacer le code PHP par un pseudo-langage, présentant les avantages suivants. Soit.
Citation : TutoCe langage est assez simple. On retrouve l'équivalent d'expressions PHP. Cela rend ce langage idéal pour être utilisé par un graphiste, qui n'a ainsi pas à apprendre à utiliser PHP, mais juste ce langage, forcément plus simple. C'est pas moins compliqué que du PHP, c'est du PHP, juste écrit d'une façon différente (la preuve étant que la fonction d'analyse consiste à traduire le code template en PHP). C'est à la rigueur plus court (pour les affichages mais pas pour les conditions par exemple) mais pas plus simple. Apprendre ce langage ou apprendre à utiliser des conditions, des boucles et des inclusions en PHP, ça a exactement le même niveau de difficulté. Or PHP étant largement plus utilisé, je pense qu'il est plus intéressant pour un graphiste d'apprendre à l'utiliser plutôt que ce langage.
Citation : TutoNous en venons donc à un deuxième avantage : la présentation est totalement séparée de la logique du code, et de la récupération des données. On peut toucher au style du site sans toucher à la logique, et vice-versa. Ce qu'on peut très bien faire en PHP seul.
Code : XML | <h1>Les news du site</h1>
<foreach ary="{$NEWS}">
<div class="news">
<h2>{NEWS.val['titre']}</h2>
<p>News postée le {NEWS.val['date_formatee']} par {NEWS.val['auteur']}</p>
<p>{NEWS.val['contenu']}</p>
</div>
</foreach>
|
Code : PHP | <h1>Les news du site</h1>
<?php foreach($news as $val): ?>
<div class="news">
<h2><?php echo $val['titre']; ?></h2>
<p>News postée le <?php echo $val['date_formatee']; ?> par <?php echo $val['auteur']; ?></p>
<p><?php echo $val['contenu']; ?></p>
</div>
<?php endforeach; ?>
|
En quoi le premier code est plus simple que le second ? Il suffit ensuite d'appeler une fonction de ce type :
Code : PHP | <?php
function include_in_context($__file, $__context = array()) {
extract($__context, EXTR_SKIP);
include $__file;
}
?>
|
Ainsi :
Code : PHP | <?php
in_context('blabla.php', array('news' => array(/* ... */)));
?>
|
Non ?
Si c'est pour éviter la syntaxe PHP, autant utiliser une solution type Django, mais traduire vers du PHP je vois mal l'intérêt, c'est déjà un langage de templates.
OH SH-
|
People are strange
Ville : Paris
Pays : France métropolitaine
Études : EFREI
|
Citation : Dentuk
Citation : TutoCe que nous allons voir ici consiste à remplacer le code PHP par un pseudo-langage, présentant les avantages suivants. Soit.
Citation : TutoCe langage est assez simple. On retrouve l'équivalent d'expressions PHP. Cela rend ce langage idéal pour être utilisé par un graphiste, qui n'a ainsi pas à apprendre à utiliser PHP, mais juste ce langage, forcément plus simple. C'est pas moins compliqué que du PHP, c'est du PHP, juste écrit d'une façon différente (la preuve étant que la fonction d'analyse consiste à traduire le code template en PHP). C'est à la rigueur plus court (pour les affichages mais pas pour les conditions par exemple) mais pas plus simple. Apprendre ce langage ou apprendre à utiliser des conditions, des boucles et des inclusions en PHP, ça a exactement le même niveau de difficulté. Or PHP étant largement plus utilisé, je pense qu'il est plus intéressant pour un graphiste d'apprendre à l'utiliser plutôt que ce langage.
Oui et non ; Concernant le fait que ce soit traduit en php, dis toi qu'au final, tout langage est interprété en langage / instructions machines... Le boulot de l'intégrateur, c'est savoir quel bloc fait quoi, et c'est tout. C'est à dire, niveau algo, il s'en fiche. Il veut qu'un tel bloc se répète tant de fois, et plus exactement faire certaines opérations sur des variables (par exemple, pour un bloc, savoir si il est à la première itération, a la dernière, quelle est l'itération courante, ... etc), ce qui est également plus simple qu'en PHP, où il faut à chaque fois tout faire à la main.... ce qui rebutera tout inconnu à PHP. Certaines particularités sont en quelques sortes prémachées. C'est là l'intérêt.
Citation : Dentuk
Citation : TutoNous en venons donc à un deuxième avantage : la présentation est totalement séparée de la logique du code, et de la récupération des données. On peut toucher au style du site sans toucher à la logique, et vice-versa. Ce qu'on peut très bien faire en PHP seul.
A la base, PHP est un moteur de template. Qui a évolué. Et disons qu'avoir une séparation plus nette peut aussi aider... Mais ça, c'est les gouts, les couleurs. Moi-même, même si j'ai développé ce fameux moteur, des fois je préfère utiliser PHP face aux templates.
Citation : Dentuk
Code : XML | <h1>Les news du site</h1>
<foreach ary="{$NEWS}">
<div class="news">
<h2>{NEWS.val['titre']}</h2>
<p>News postée le {NEWS.val['date_formatee']} par {NEWS.val['auteur']}</p>
<p>{NEWS.val['contenu']}</p>
</div>
</foreach>
|
| <h1>Les news du site</h1>
<?php foreach($news as $val): ?>
<div class="news">
<h2><?php echo $val['titre']; ?></h2>
<p>News postée le <?php echo $val['date_formatee']; ?> par <?php echo $val['auteur']; ?></p>
<p><?php echo $val['contenu']; ?></p>
</div>
<?php endforeach; ?>
|
En quoi le premier code est plus simple que le second ?
Là tu prends le morceau simple où il n'y a, en effet, aps vraiment de différences. D'ailleurs, le second est plus ou moins l'interprétation PHP du premier, à peu de choses près... Mais par exemple, comme je le disais plus haut, si tu as besoin de certaines particularité du style
Code : XML | <foreach ary="{$news}">
<if cond="{$news.is_first}">
Je suis le premier élément
</if>
/* bla bla bla */
<if cond="{$news.is_last}">
Je suis le dernier élément !
</if>
</foreach>
|
N'est-ce pas plus clair et simple que
Code : PHP 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 | <?php
$i = 0;
$count = count($news);
foreach ($news as $n) {
if ($i == 0) {
?>Je suis le premier élément<?php
}
/* bla bla bla */
if ($i == ($count - 1)) {
?>Je suis le dernier élément !<?php
}
++$i;
}
|
Mon choix est vite fait, surtout pour quelqu'un non initié...
Citation : DentukIl suffit ensuite d'appeler une fonction de ce type :
Code : PHP | <?php
function include_in_context($__file, $__context = array()) {
extract($__context, EXTR_SKIP);
include $__file;
}
?>
|
Ainsi :
Code : PHP | <?php
in_context('blabla.php', array('news' => array(/* ... */)));
?>
|
Non ?
Ben techniquement c'est ce que fait le moteur de tpl...
Code : PHP | <?php
$tpl = new Talus_TPL;
$tpl->set(array('news' => array(/* ... */)));
$tpl->parse('blabla.html');
|
Citation : Dentuk
Si c'est pour éviter la syntaxe PHP, autant utiliser une solution type Django, mais traduire vers du PHP je vois mal l'intérêt, c'est déjà un langage de templates.
Ben disons que c'est le même intérêt que Twig et autres Jinja ; PHP n'est plus vraiment un moteur de template à présent... Ca a été sa base, mais maintenant il a évolué en véritable langage de script.
|
Yamo...
Études : ENSEA
|
Ok.
Pour ce qui est de l'optimisation, ça reste convenable parce que, si j'ai bien compris le code source, ton langage est en fait compilé vers du PHP, et la traduction n'a lieu qu'une fois et pas à chaque fois qu'on appelle la page. Après si je devais coder un tel système de traduction je ferais en sorte que la traduction soit faite avant l'envoi sur le serveur plutôt que ce soit le serveur qui ait à vérifier à chaque requête si la traduction a été effectuée, et dans le cas contraire la fasse. Mais bon, pourquoi pas.
C'est surtout qu'après une lecture du tuto en diagonale (j'avoue), le langage ne semblait rien offrir de plus par rapport au PHP pur. Il faudrait souligner le fait qu'il y a des tâches facilitées dans la liste des avantages.
Je maintiens que ton langage reste trop proche du PHP à mon goût par exemple dans le choix des noms. Et je reste dubitatif par rapport à la clarté et la concision d'une syntaxe XML mélangée à des {, des } et des $, notamment pour un non-initié. Je trouve la syntaxe Django plus efficace dans cette optique. Là on dirait que tu as voulu faire du XML, mais que ça rendait les codes encore plus longs à écrire qu'en PHP, alors t'as pris des raccourcis qui rendent le tout plus rapide à écrire mais aussi plus confus.
Par exemple la syntaxe des conditions :
Code : XML | <if condition="{$VAR} == 3">
{\VAR} vaut 3
<elseif condition="{$VAR} == 4" />
{\VAR} vaut 4
<elseif condition="{$VAR} == 5" />
{\VAR} vaut 5
/* et ainsi de suite */
<else />
{\VAR} a une autre valeur
</if> /* on n'oublie pas de fermer le if */
|
À la première lecture on dirait qu'on rentre dans le bloc uniquement si la condition est respectée. Mais non, les elseif sont dans le bloc if. Donc la syntaxe XML, ainsi utilisée, me parait douteuse. Une version plus XML mais plus dure à traduire et plus pompeuse (donc inadaptée) serait :
Code : XML | <do>
<when predicate="{$VAR} == 3">{\VAR} vaut 3</when>
<when predicate="{$VAR} == 4">{\VAR} vaut 4</when>
<when predicate="{$VAR} == 5">{\VAR} vaut 5</when>
<!-- et ainsi de suite -->
<otherwise>{\VAR} a une autre valeur</otherwise>
</do>
|
Ce que j'essaie de dire, c'est que le XML n'est pas vraiment adapté : il alourdit le tout si on veut bien l'utiliser. Par exemple les cond= dans les if et les ary= dans les foreach gênent la lecture. Qu'est-ce qui t'a poussé à choisir ça ?
Pour l'exemple que j'ai pris c'était celui du tuto en fait.
OH SH-
|
People are strange
Ville : Paris
Pays : France métropolitaine
Études : EFREI
|
Qu'entends-tu par vérifier avant le serveur si il faut en effet recompiler ou non le template ?
Concernant les délimiteurs, c'est encore une fois une question de gout. Que ce soit {{ }} ou {}, la différence n'est pas des plus énorme... Après, pour {% %} ou {$} (et autres pseudo-xml -- d'ou le pseudo en fait), il n'y a pas non plus une très grande différence...
Pour les attributs, je vais t'avouer que c'est les premiers venu en tête qui me sont passé par là et que je trouvais assez explicites par leur nom (leurs noms complets étant "condition" et "array"). Je sais que je reste assez proche de PHP, mais finalement, c'est le cas aussi des autres moteurs (sauf que c'est "for", certes). Mais maintenant que tu m'y fais penser, j'ai en effet fait une erreur : au lieu de choisir "foreach" pour les boucles, j'aurais pu choisir par exemple "loop" qui aurait été bien plus clair pour un non-initié... Avant, il y avait le concept du "block", qui remplissait assez bien sa tâche.
De toutes manières, je pense refactorer toussa d'ici la v2. Enfin, encore faudrait-il que je mette mes idées au clair pour celle-ci...
|
Yamo...
Études : ENSEA
|
Citation : Talus Qu'entends-tu par vérifier avant le serveur si il faut en effet recompiler ou non le template ? Non ce que je voulais dire c'était :
- soit faire du traducteur un programme « pur et dur » envoyé aux développeurs/designers, ainsi ce sont les fichiers traduits qui sont mis en ligne et pas les .tpl ;
- soit passer par une interface d'administration pour envoyer les fichiers .tpl, c'est alors elle qui effectue la traduction quand elle en reçoit.
Bon là c'est un peu radical mais l'idée c'est de réduire le « code qui est appelé et/ou inclus à chaque fois » au strict minimum (cf la fonction que j'ai écrite plus haut par exemple). Parce que derrière ce code qui est certes simple à mettre en place :
Code : PHP | <?php
$tpl = new Talus_TPL;
$tpl->set(array('news' => array(/* ... */)));
$tpl->parse('blabla.html');
?>
|
Il y a au minimum 1241 lignes de PHP à interpréter à chaque fois que quelqu'un demande la page (Main, Cache et Parser). Ça me parait énorme. Tu pourrais déjà alléger ça en n'incluant les 433 lignes de Parser.php (ce qui se fait à l'utilisation de la classe liée) que si c'est nécessaire, autrement dit en le faisant dans Talus_TPL::str() plutôt que Talus_TPL::__construct() qui est toujours appelée.
Citation : TalusConcernant les délimiteurs, c'est encore une fois une question de gout. Que ce soit {{ }} ou {}, la différence n'est pas des plus énorme... Après, pour {% %} ou {$} (et autres pseudo-xml -- d'ou le pseudo en fait), il n'y a pas non plus une très grande différence...
Pour les attributs, je vais t'avouer que c'est les premiers venu en tête qui me sont passé par là et que je trouvais assez explicites par leur nom (leurs noms complets étant "condition" et "array"). Je sais que je reste assez proche de PHP, mais finalement, c'est le cas aussi des autres moteurs (sauf que c'est "for", certes). Mais maintenant que tu m'y fais penser, j'ai en effet fait une erreur : au lieu de choisir "foreach" pour les boucles, j'aurais pu choisir par exemple "loop" qui aurait été bien plus clair pour un non-initié... Avant, il y avait le concept du "block", qui remplissait assez bien sa tâche.
Le problème n'est pas que les noms des attributs soient mals choisis ou quoi, c'est la présence même d'attributs qui me gène : ça « coupe » la lecture du code, son « flow », sans rien apporter. Un peu comme si on écrivait (en exagérant) : <phrase sujet="tu" verbe="vas" complément="bien" ponctuation="?" /> dès qu'on voulait dire un truc.
Qu'est-ce qui est le plus facile à lire ?
Code : XML | <if condition="whatever">prout</if>
<if whatever>prout</if>
|
Bon après si on vire les attributs faut carrément virer le pseudo-XML sous peine d'avoir des soucis pour tester <if a>2>. J'explique juste pourquoi je n'aime pas ce pseudo-XML.
OH SH-
|
People are strange
Ville : Paris
Pays : France métropolitaine
Études : EFREI
|
Faire un programme de traitement (que ce soit interface d'admin, programme externe) complifierait inutilement et grandement la chose pour quoi au final ? Pas grand chose...
Concernant les appels, oui et non ; en effet, j'ai tout de même besoin de connaître les classes que je dois appeler ! Avant que je ne mette en place le principe de la dépendance, et ainsi augmenter la flexibilité du moteur, je procédais comme tu l'indiques. En gros, le cache n'était chargé que dans parse(), et le parseur que dans str()...
Mais j'ai du faire un choix pratique. Soit j'inclus en effet tout Parser.php dès le début (ou alors une autre classe qui implémente la bonne interface (Talus_TPL_Parser_Interface, Talus_TPL_Cache_Interface dans le cas présent), mais bref, elle doit être initialisée), pour qu'on puisse faire les modifs nécessaire... Tu vois un peu le problème ?
Ce que je peux toujours faire, à la rigueur, dans parse() & str(), c'est vérifier si parser & cache sont null, et si oui, alors allouer moi-même une classe... Et ne pas m'en occuper dans __construct(). Mais faut l'avouer, c'est assez moche... !
Pour la syntaxe, oui tu marques un point... Quoique, <if <cond>> face à <if cond="<cond>">, la différence est minime, non ? ç part quelques caractères de plus, certes, ...
|
Yamo...
Études : ENSEA
|
Citation : Talus Faire un programme de traitement (que ce soit interface d'admin, programme externe) complifierait inutilement et grandement la chose pour quoi au final ? Pas grand chose...
L'interface d'admin c'est pas tellement plus compliqué, c'est surtout plus dur à faire de façon modulable et réutilisable par d'autres, on peut au mieux fournir la fonction de traduction et éventuellement une interface « par défaut ». Après c'est moins pratique à partager que ton système actuel, en effet. Mais il doit y avoir un gain en performance assez conséquent si la fonction d'appel des pages est réduite au strict minimum.
Citation : TalusConcernant les appels, oui et non ; en effet, j'ai tout de même besoin de connaître les classes que je dois appeler ! Avant que je ne mette en place le principe de la dépendance, et ainsi augmenter la flexibilité du moteur, je procédais comme tu l'indiques. En gros, le cache n'était chargé que dans parse(), et le parseur que dans str()... <>
Mais j'ai du faire un choix pratique. Soit j'inclus en effet tout Parser.php dès le début (ou alors une autre classe qui implémente la bonne interface (Talus_TPL_Parser_Interface, Talus_TPL_Cache_Interface dans le cas présent), mais bref, elle doit être initialisée), pour qu'on puisse faire les modifs nécessaire... Tu vois un peu le problème ?
Ce que je peux toujours faire, à la rigueur, dans parse() & str(), c'est vérifier si parser & cache sont null, et si oui, alors allouer moi-même une classe... Et ne pas m'en occuper dans __construct(). Mais faut l'avouer, c'est assez moche... ! Certes c'est assez moche mais ça divise presque par deux le code PHP chargé dans le cas général, c'est pas négligeable je pense. Tu peux envelopper ça dans une méthode load_if_not_set_parser ou ce que tu veux pour que ça paraisse moins moche. Le cache lui tu en auras toujours besoin.
Citation : TalusPour la syntaxe, oui tu marques un point... Quoique, <if <cond>> face à <if cond="<cond>">, la différence est minime, non ? ç part quelques caractères de plus, certes, ... Le souci c'est pas les caractères en plus, c'est le confort de lecture. Un code est plus simple à suivre dans sa continuité et à comprendre globalement s'il n'y a rien (en tout cas pas de texte lisible parce que ça détourne l'attention) entre un "if" et la condition qui l'accompagne (par exemple). Après qu'autour ce soit des <>, des {} ou des <<#{\/}#>> peu importe.
Un exemple bidon avec une syntaxe inventée :
Code : XML 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 | <foreach ary="{$passions}">
<p>J'aime les
<if cond="{$passions.val} == 'prout'">
prouts
<elif cond="{$passions.val} == 'zizi'" />
zizis
<else />
fesses
</if>
!</p>
</foreach>
<< loopover passions >>
<p>J'aime les
<< if passions.val == 'prout' >>
prouts
<< elif passions.val == 'zizi' >>
zizis
<< else >>
fesses
<< /if >>
!</p>
<< /loopover >>
|
L'objet lié à une condition/boucle y est directement rattaché dans la deuxième syntaxe, je trouve ça plus facile à lire que quand on doit lire « ary= » ou « cond= » à chaque fois.
Dans le premier code si ton œil essaie de regarder le bloc if, il voit if cond, elif cond, else. Tu n'as pas une vision globale, tu es obligé de regarder balise par balise.
OH SH-
|
People are strange
Ville : Paris
Pays : France métropolitaine
Études : EFREI
|
Citation : DentukCitation : TalusFaire un programme de traitement (que ce soit interface d'admin, programme externe) complifierait inutilement et grandement la chose pour quoi au final ? Pas grand chose...
L'interface d'admin c'est pas tellement plus compliqué, c'est surtout plus dur à faire de façon modulable et réutilisable par d'autres, on peut au mieux fournir la fonction de traduction et éventuellement une interface « par défaut ». Après c'est moins pratique à partager que ton système actuel, en effet. Mais il doit y avoir un gain en performance assez conséquent si la fonction d'appel des pages est réduite au strict minimum.
Techniquement, c'est déjà réduit au strict minimum. Il y a juste une vérification comme quoi le cache n'est pas expiré (une simple comparaison de timestamps / vérif d'existence du cache). Si le cache existe et est valide, il y a juste une inclusion avec contexte, comme le montrait ta fonction. Sinon, y'a juste l'étape de compilation en plus, qui n'est exécutée qu'une seule fois ; au final, c'est bien plus avantageux que l'utilisation d'un truc à part...
La syntaxe que tu proposes me plaît. Mais du à l'ancienneté du moteur (4 ans), c'est dur de pousser d'aussi gros changements... Surtout quand il n'y a pas vraiment de compatibilité, comme ici. :/
Aussi, le truc qui m'arrange pas (soucis qui n'existe pas dans Twig et moteurs dérivés de Jinja), c'est que je suis obligé d'avoir {$var} au lieu de var... Pour les reconnaître. En effet, j'ai pas vraiment de parseur par tokens (ce qui changera dans la v2). J'en profiterai alors pour changer la syntaxe comme il le faut...
|
Yamo...
Études : ENSEA
|
Citation : Talus Techniquement, c'est déjà réduit au strict minimum. Il y a juste une vérification comme quoi le cache n'est pas expiré (une simple comparaison de timestamps / vérif d'existence du cache). Si le cache existe et est valide, il y a juste une inclusion avec contexte, comme le montrait ta fonction. Sinon, y'a juste l'étape de compilation en plus, qui n'est exécutée qu'une seule fois ; au final, c'est bien plus avantageux que l'utilisation d'un truc à part... Au niveau du code appelé oui, au niveau du code inclus non, ce qui a aussi son importance en PHP vu que l'interprétation se fait « en dur » à chaque inclusion de page (pas de bytecode comme en python/java/whatever à ma connaissance). Je ne sais pas l'ordre de grandeur du temps que met PHP à analyser un code de mille lignes mais l'idée est là.
Citation : TalusLa syntaxe que tu proposes me plaît. Mais du à l'ancienneté du moteur (4 ans), c'est dur de pousser d'aussi gros changements... Surtout quand il n'y a pas vraiment de compatibilité, comme ici. :/
Aussi, le truc qui m'arrange pas (soucis qui n'existe pas dans Twig et moteurs dérivés de Jinja), c'est que je suis obligé d'avoir {$var} au lieu de var... Pour les reconnaître. En effet, j'ai pas vraiment de parseur par tokens (ce qui changera dans la v2). J'en profiterai alors pour changer la syntaxe comme il le faut... Oui c'est pas un changement léger, à toi de voir si ça vaut la peine ou pas et quand le faire.
OH SH-
|
People are strange
Ville : Paris
Pays : France métropolitaine
Études : EFREI
|
En tout cas, le ticket est ouvert sur l'espace github.
Merci pour les remarques. Si tu en as d'autres, n'hésites à passer par là-bas (je ne lis pas forcément les commentaires ici)
|
vincent1870
Trouvez une formation
Suggestions
Facebook
Google+