🌍
Français
Oui, je te rejoins je fais mes propres .tpl extensions
De mon point de vue, çà me semble tiré par les cheveux (je suis pas capable de capilotracter) de vouloir faire des choses aussi complexes :
1/ combien d'administrateurs de galerie ont de tels besoins, et sont capables de coder du php ou générer des templates smarty (et motivés pour le faire) ?
2/ les risques de plantages sont accrus (plus tu parses, plus y a de risques que le contenu à parser pose problème)
3/ va expliquer à l'utilisateur qui veut utiliser une accolade dans son texte doive utiliser des codes spécifiques
Pour moi, on s'approche de l'usine à gaz qui essaye de tout faire et on s'éloigne de l'application robuste avec un usage simple.
A partir du moment où on commence à renter dans des besoins aussi précis et complexes, je pense qu'il faut se poser la question d'une solution appropriée :
- création d'un template perso
- réalisation d'un plugin
Je me pose quelques questions capilotractables.
[hook=my_local_function(args)]
La fonction ne saurait-elle pas faire un global $user;
et retrouver ainsi le username?
La fonction ne saurait-elle pas au besoin faire:
$all = $template->get_template_vars();
Ou une fonction équivalente que nous pourrions proposer.
Cela sous-entend, je veux bien l'admettre qu'il ne faut pas faire d'assign, de clear_cache ou de display, en espérant avoir une prise en compte par le module php qui est l'appelant dans _data.
L'objectif voulu n'est pas, il me semble, de savoir de coder du smarty dans du smarty.
Le vrai besoin du webmaster est plutôt de savoir ajouter un script externe simplement.
Script externe qui fera sans doute quelques "echo" dans la logique pure et stricte de php (sans se soucier de la présence d'un cache de Smarty ou des fonctions de Smarty).
Serai-je à coté du besoin? Et si éloigné une fois encore d'une solution simple?
Je préfère utiliser la syntaxe smarty dans un bloc perso pour plusieurs raisons:
- On peut insérer facilement du php
- On peut utiliser les variables déjà assignées à smarty (comme par exemple {$USERNAME})
- On ne parse qu'une seule fois le contenu grace à la mise en cache...
P@t a écrit:
grum a écrit:
Ben... Et pourtant : PHP parse les fichiers avant des les interpréter..
Bon, la on chipote ;-)
Pas vraiment, c'est le grand débat des spécialistes du PHP.
PHP est le premier parseur, tout le monde est d'accord en principe, mais doit-on parser du code avec PHP?
2 écoles s'affrontent les pour et les contre.
Piwigo utilise Smarty pour parser du code (autant dire qu'on est pour).
Smarty est limite pour autoriser le parsing du PHP.
Et maintenant, on va parser du texte pour résoudre des appels php.
Ne pourrait-on pas plutôt coder [hook=my_local_function(args)], par exemple ?
Et laisser le webmaster de coder sa fonction dans le plugin personnel ?
Je suis persuadé que l'appel de la fonction existe déjà dans Smarty, il devrait être suffisant de l'appeler, non?
C'est n'est qu'une idée ou de faire quelque chose de ce genre.
Je n'ai pas réfléchi plus à cette question encore.
grum a écrit:
Ben... Et pourtant : PHP parse les fichiers avant des les interpréter..
Bon, la on chipote ;-)
Bref... perso je serais assez partant (pour PWG Stuffs en tout cas) pour pouvoir faire du smarty dans les blocs persos... éventuellement désactiver la balise {php} par sécurité (quoique ce n'est pas franchement un problème puisque seul les admins peuvent ajouter ou modifier un bloc).
Par contre, pour éviter de devoir parser le fichier systématiquement, il faut gérer la mise en cache, et donc un identifiant de compilation... mais smarty permet de faire ca sans trop de soucis...
P@t a écrit:
Le php est un language qui est interprété, et non pas parsé....
Ben... Et pourtant : PHP parse les fichiers avant des les interpréter..
Le fichier php suivant :
<html>
<body>
<div>
<p>
blablah
</>
<?php
echo "truc";
?>
<p> machin</p>
<?php
echo "bidule";
?>
</div>
</body>
</html>nécessite forcément une étape de parsing ne serait-ci que pour détecter les balises <?php> ;-)
P@t a écrit:
Si on veut intégrer des balises smarty (comme {php}{/php} pour pouvoir mettre du php) dans un bloc du menubar (ou dans un bloc de pwg stuffs), il faudrait d'abord parser le contenu envoyé (grace au parser de smarty) avant de l'envoyer au template, ce qui est tout à fait faisable... mais pas très rentable au niveau des perfs!
Tout à fait d'accord.
Et je rajouterais que de permettre une telle chose serait de toutes façon assez risqué...
LucMorizur a écrit:
Smarty contient donc un parseur PHP en interne ? On peut avoir une interprétation différente d'un code PHP entre celui donné à Smarty, et celui interprété sur le serveur, dûe à une différence de version de parseur PHP, par exemple ?
On s'embrouille beaucoup ici!
Le php est un language qui est interprété, et non pas parsé.... contrairement au bbcode, au xml, au language smarty, etc...
Si smarty génère un fichier php après avoir parsé un fichier tpl, c'est uniquement pour le mettre en cache, et ainsi gagner en performance.
Ainsi, un fichier .tpl n'est parsé qu'une seule fois... ensuite, c'est toujours le fichier php en cache qui interprété (et non pas parsé!).
Si on veut intégrer des balises smarty (comme {php}{/php} pour pouvoir mettre du php) dans un bloc du menubar (ou dans un bloc de pwg stuffs), il faudrait d'abord parser le contenu envoyé (grace au parser de smarty) avant de l'envoyer au template, ce qui est tout à fait faisable... mais pas très rentable au niveau des perfs!
grum a écrit:
on sort un peu du sujet Piwigo en abordant la façon dont Smarty fonctionne...
C'est vrai. Désolé forum6691 ; j'espère néanmoins que l'intérêt de la discussion sera quand même là.
(...)
Mais le fichier "précompilé" qui est un fichier PHP, génère bien en sortie un fichier HTML lequel n'est pas parsé par PHP.
Smarty contient donc un parseur PHP en interne ? On peut avoir une interprétation différente d'un code PHP entre celui donné à Smarty, et celui interprété sur le serveur, dûe à une différence de version de parseur PHP, par exemple ?
Mais bon, ces questions sont assez peu importantes je pense ; globalement, ça va fonctionner de telle sorte qu'en gros les templates TPL génèrent un affichage HTML, ce qui nous intéresse en fin de compte.
Merci grum pour ces précisions intéressantes.
ddtddt a écrit:
grum a écrit:
Dans la même idée, inclure du PHP directement dans un template ne sert à rien : si l'on veut vraiment inclure du code dans le template, Smarty dispose d'instructions spécifiques pour le faire.
et les instructions spécifiques pour le faire dans AMM cela fonctionne ?
Je n'ai pas testé, mais probablement pas car à ma connaissance Smarty ne parse pas le contenu de ses variables. pour parser une variable, il faut le faire manuellement avant d'alimenter Smarty.
grum a écrit:
Dans la même idée, inclure du PHP directement dans un template ne sert à rien : si l'on veut vraiment inclure du code dans le template, Smarty dispose d'instructions spécifiques pour le faire.
et les instructions spécifiques pour le faire dans AMM cela fonctionne ?
on sort un peu du sujet Piwigo en abordant la façon dont Smarty fonctionne...
mais bon, Smarty exploite un template écrit en en pseudo-HTML (du fait qu'il contient des instruction Smarty, ce n'est pas vraiment du HTML), et génère effectivement un fichier PHP à partir de ce template.
Mais le fichier PHP généré fait toujours référence à des variables. Au moment de l'utilisation d'un template, deux cas (dans les grandes lignes) :
- c'est la première fois qu'il est appellé : Smarty "précompile" le template et génère un fichier PHP, puis exécute le fichier PHP généré
- ce n'est pas la première fois qu'il est appellé : Smarty exécute le fichier PHP correspondant au template
Mais le fichier "précompilé" qui est un fichier PHP, génère bien en sortie un fichier HTML lequel n'est pas parsé par PHP.
Donc le code PHP paramétré dans la section personnalisée d'AMM ne se retrouve pas dans le template précompilé, mais bien dans un fichier HTML.
Dans la même idée, inclure du PHP directement dans un template ne sert à rien : si l'on veut vraiment inclure du code dans le template, Smarty dispose d'instructions spécifiques pour le faire.
grum a écrit:
(...) Smarty ne parse pas le contenu de ses variables, il se contente (à juste titre) de générer du HTML.
Juste pour la précision technique, ne serait-ce pas plutôt du PHP, que Smarty génère ? Lequel PHP génère lui-même du HTML, lorsque interprété par le serveur ?
Merci pour cette réponse rapide (on est dimanche matin quand même) précise et très technique
Je vais regarder plutôt la deuxième solution.
Cyril
Je ne suis pas chez moi ce WE, donc pas d'environnement ni code source à dispo.
Mais de mémoire, comme çà : le contenu d'une section personnelle n'est tout simplement pas parsé car stocké dans une variable du template. Or Smarty ne parse pas le contenu de ses variables, il se contente (à juste titre) de générer du HTML.
Ce qui explique pourquoi du JS fonctionne et pas du PHP.
Pour ton besoin, deux solutions :
- faire le parser XML en JS
- utiliser un plugin perso pour affecter le contenu du menu (tu trouveras les bases dans le topic topic:16135)