Piwigo.org

P@t · 2009-09-28 00:46:32

Je pense qu'on peut faire mieux...

Avec cette solution, le filtre sera chargé pour tous les fichiers templates de la page (dans ton exemple: header, tags, footer).
En plus on est obligé de préciser if (script_basename() == 'tags')

Il faudrait donc utiliser les filtres uniquement pour un handler spécifique ('tags', 'header', footer', etc...)

Donc faire comme pour les plugins:

$template->set_external_filter('tags', 'test_filter', 60);

Avec une priorité par défaut de 50, tant qu'à faire.

Pour les templates compilés, smarty permet également de faire beaucoup mieux, grace aux identifiants de compilation.
Il suffit de définir un identifiant de compilation différent si un ou plusieurs filtre est chargé.

Bref, je commit... tu me dis ce que tu en pense, ca sera plus simple...

P@t · 2009-09-28 01:47:12

Voila, c'est commité, dis-moi ce que t'en penses...
Pour reprendre ton exemple:

1. Purge des templates inutile car nouvel identifiant de compilation.

2. Cible: on précise le handler, le filtre ne s'applique que sur le template voulu.

Code:

add_event_handler('loc_begin_page_header', 'my_plugin_function_for_tags', 60);

function my_plugin_function_for_tags()
{
  global $template;

  $template->set_external_filter('tags', 'test_filter', 60);
}

La fonction préfiltre ne change pas....

Code:

function test_filter($source, &$smarty)
{
  $orig = '{if $display_mode == \'cloud\'}';
  $my_data = '<a>new link in head</a> {if $display_mode == \'cloud\'}';
  return str_replace($orig,$my_data, $source);
}

VDigital · 2009-09-28 07:27:37

Et encore un astuce pour utilisateurs très mais vraiment très avancés.
Mercis à P@t pour la révision,
Mathias pour avoir insister dans le maintien de la logique 1.7,
et Nicolas pour sa compréhension.

EX-FTB: Ils ont trouvé! Un brin complexe (toutefois le code final est assez simple) mais l'important comme le dit Mathias c'est que: ça marche!
;-)

mathiasm · 2009-09-29 00:30:37

P@t a écrit:
Voila, c'est commité, dis-moi ce que t'en penses...
Pour reprendre ton exemple:

1. Purge des templates inutile car nouvel identifiant de compilation.

2. Cible: on précise le handler, le filtre ne s'applique que sur le template voulu.

Très bien, merci.
Je n'avais pas approfondi le cas des compile_id, je savais qu'on pouvait faire mieux. Merci de t'être penché dessus.

Concernant la cible, attention. Le parse est associé au handle, qui contient l'ensemble des templates. Le if dans le main.inc.php servait à limiter au cas où le masque de recherche du filtre pouvait se retrouver dans plusieurs tpl (genre </head> ou </h2>).
Donc avec le handle picture, ton filtre s'appliquera quand même aux templates picture.tpl, picture_nav.tpl et picture_content.tpl.

Petite question supplémentaire: à quoi te sert l'unload et la restore du compile_id (qui est lié au handle et pas au template .tpl ?)

P@t · 2009-09-29 01:50:45

mathiasm a écrit:
Concernant la cible, attention. Le parse est associé au handle, qui contient l'ensemble des templates. Le if dans le main.inc.php servait à limiter au cas où le masque de recherche du filtre pouvait se retrouver dans plusieurs tpl (genre </head> ou </h2>).
Donc avec le handle picture, ton filtre s'appliquera quand même aux templates picture.tpl, picture_nav.tpl et picture_content.tpl.

Pas tout à fait d'accord....
Si je veux modifier picture_content.tpl, c'est le handle 'default_content' qu'il faut utiliser (picture.php, ligne 183).
Les prefiltres pour le handle 'picture' n'affecteront pas picture_content.tpl, car picture.tpl et picture_content.tpl sont parsés séparément avec deux handles distincts.

En revanche, tu as raison pour picture_nav.tpl. Le fichier est inclus directement dans picture.tpl.
Il faut donc utiliser l'handle 'picture' pour le modifier. Ca ne me parait pas gênant...

mathiasm a écrit:
Petite question supplémentaire: à quoi te sert l'unload et la restore du compile_id (qui est lié au handle et pas au template .tpl ?)

L'unload, c'est pour enlever les filtres après avoir parsé un template... Imaginons que je mette un préfiltre sur le header... Si je ne le décharge pas après, le filtre sera appliqué aux templates suivants (index.tpl et footer.tpl par exemple). Ca évite les cas ou le masque de recherche du filtre se retrouve dans plusieurs tpl, et en plus, ca allège le temps de calcul...
La restauration du compile_id, c'est pour les fichiers de cache. Si je ne le restaure pas, il va me générer d'autres fichiers de cache pour tous les templates à venir. Exemple: si je met un prefiltre sur le header, il va me générer un nouveau fichier de cache pour le header (normal), mais aussi pour l'index et le footer... Il me faut donc un nouveau compile_id uniquement pour les templates utilisant un préfiltre.

Dernière modification par P@t (2009-09-29 10:50:12)

VDigital · 2009-09-29 07:42:16

Je dois reconnaître que le topic ne s'adresse plus qu'à quelques experts même si j'ai personnellement introduit le filtrage par les "handles" (Cf. template-extension).

mathiasm · 2009-09-29 21:49:49

P@t a écrit:
mathiasm a écrit:
Concernant la cible, attention. Le parse est associé au handle, qui contient l'ensemble des templates. Le if dans le main.inc.php servait à limiter au cas où le masque de recherche du filtre pouvait se retrouver dans plusieurs tpl (genre </head> ou </h2>).
Donc avec le handle picture, ton filtre s'appliquera quand même aux templates picture.tpl, picture_nav.tpl et picture_content.tpl.
Pas tout à fait d'accord....
Si je veux modifier picture_content.tpl, c'est le handle 'default_content' qu'il faut utiliser (picture.php, ligne 183).
Les prefiltres pour le handle 'picture' n'affecteront pas picture_content.tpl, car picture.tpl et picture_content.tpl sont parsés séparément avec deux handles distincts.
En revanche, tu as raison pour picture_nav.tpl. Le fichier est inclus directement dans picture.tpl.
Il faut donc utiliser l'handle 'picture' pour le modifier. Ca ne me parait pas gênant...

OK pour picture_content.
Ce n'est pas grave, il faut juste s'en souvenir quand on crée son masque de recherche. J'avais utilisé un marqueur du nav qui était présent plusieurs fois dans picture.tpl. Mais les tests sont là pour ça.

P@t a écrit:
mathiasm a écrit:
Petite question supplémentaire: à quoi te sert l'unload et la restore du compile_id (qui est lié au handle et pas au template .tpl ?)
L'unload, c'est pour enlever les filtres après avoir parsé un template... Imaginons que je mette un préfiltre sur le header... Si je ne le décharge pas après, le filtre sera appliqué aux templates suivants (index.tpl et footer.tpl par exemple). Ca évite les cas ou le masque de recherche du filtre se retrouve dans plusieurs tpl, et en plus, ca allège le temps de calcul...

Je viens de comprendre mon erreur: on associe les préfiltres à un handle, mais pour Smarty, les préfiltres s'appliquent à tout ce qui est parsé, ce qui explique pourquoi j'ai pu appliqué un préfiltre sur </header> en travaillant avec le handle de picture.
C'était donc une grosse faute de ma part de ne pas avoir fait l'unload. Re-merci P@t.

mathiasm · 2009-09-29 21:53:28

VDigital a écrit:
Je dois reconnaître que le topic ne s'adresse plus qu'à quelques experts même si j'ai personnellement introduit le filtrage par les "handles" (Cf. template-extension).

Oui, l'implémentation est complexe, mais son usage au travers des plugins va permettre de mieux pérenniser une modification de template que par template-extension, qui oblige à dupliquer l'existant et donc à perdre les évolutions.

Les template-extensions sont très bien pour une modif personnelle des templates, pas pour un plugin qui ne sait pas à quel template il s'attaque (FloOS, yoga, ...).

flop25 · 2009-09-29 23:10:37

heu vous pourriez faire une synthèse une fois fini ?
merci

Dernière modification par flop25 (2009-09-29 23:10:52)

mathiasm · 2009-09-30 01:10:02

flop25 a écrit:
heu vous pourriez faire une synthèse une fois fini ?
merci

Nan :-D

Je crois qu'on est bon, là en fait. Y'a plus qu'à documenter FR/EN au moins. P@t, tu confirmes ?

P@t · 2009-09-30 01:48:32

mathiasm a écrit:
Je crois qu'on est bon, là en fait. Y'a plus qu'à documenter FR/EN au moins. P@t, tu confirmes ?

Pour moi, c'est ok... j'aimerai quand meme que rvelices (le spécialiste de smarty!) nous donnes son avis la dessus ;-)
Je lui envoie un MP.

VDigital · 2009-09-30 05:53:57

mathiasm a écrit:
VDigital a écrit:
Je dois reconnaître que le topic ne s'adresse plus qu'à quelques experts même si j'ai personnellement introduit le filtrage par les "handles" (Cf. template-extension).
Oui, l'implémentation est complexe, mais son usage au travers des plugins va permettre de mieux pérenniser une modification de template que par template-extension, qui oblige à dupliquer l'existant et donc à perdre les évolutions.

Les template-extensions sont très bien pour une modif personnelle des templates, pas pour un plugin qui ne sait pas à quel template il s'attaque (FloOS, yoga, ...).

J'avais tout à fait compris et j'adhère totalement à cette façon de procéder.
La customisation locale c'est le rôle des template-extensions (Merci encore à chrisaga pour l'idée).
L'usage des Prefilters (et bientôt je présume des Postfilters) c'est idéal pour les plugins et le plugin personnel.

Merci d'avance à l'ami rvelices.

ddtddt · 2009-09-30 07:04:58

P@t a écrit:
Je lui envoie un MP.

Tu peux également utiliser la nouvelle fonction de notification ;-)

VDigital · 2009-09-30 07:19:23

La notification manque un peu d'un titre cohérent...
Cela fait très spam à l'arrivée dans la boite.

rvelices · 2009-09-30 18:59:03

P@t a écrit:
mathiasm a écrit:
Je crois qu'on est bon, là en fait. Y'a plus qu'à documenter FR/EN au moins. P@t, tu confirmes ?
Pour moi, c'est ok... j'aimerai quand meme que rvelices (le spécialiste de smarty!) nous donnes son avis la dessus ;-)
Je lui envoie un MP.

Je pense que c'est exactement ce qu'il fallait faire. Un petit détail sur $compile_id .= $callback;
La callback peut etre une array pour invoquer une méthode d'une classe/objet auquel cas il me semble que la concatenation ne donnera pas qq chose "d'unique" ...

Piwigo.org

Annonce

#16 2009-09-28 00:46:32

Re: Plugin et template

#17 2009-09-28 01:47:12

Re: Plugin et template

Code:

Code:

#18 2009-09-28 07:27:37

Re: Plugin et template

#19 2009-09-29 00:30:37

Re: Plugin et template

P@t a écrit:

#20 2009-09-29 01:50:45

Re: Plugin et template

mathiasm a écrit:

mathiasm a écrit:

#21 2009-09-29 07:42:16

Re: Plugin et template

#22 2009-09-29 21:49:49

Re: Plugin et template

P@t a écrit:

mathiasm a écrit:

P@t a écrit:

mathiasm a écrit:

#23 2009-09-29 21:53:28

Re: Plugin et template

VDigital a écrit:

#24 2009-09-29 23:10:37

Re: Plugin et template

#25 2009-09-30 01:10:02

Re: Plugin et template

flop25 a écrit:

#26 2009-09-30 01:48:32

Re: Plugin et template

mathiasm a écrit:

#27 2009-09-30 05:53:57

Re: Plugin et template

mathiasm a écrit:

VDigital a écrit:

#28 2009-09-30 07:04:58

Re: Plugin et template

P@t a écrit:

#29 2009-09-30 07:19:23

Re: Plugin et template

#30 2009-09-30 18:59:03

Re: Plugin et template

P@t a écrit:

mathiasm a écrit:

Pied de page des forums