rvelices a écrit:

ddtddt a écrit:

S'il y en a un "facile" je veux bien regarder !

admin/group_perm et/ou admin/group_list ?

Et ensuite, je pense que si tu veux faire un bien formateur, c'est admin/user_list.php ;-)

rub a écrit:

C'est mis...
Ca fonctionne sous xampp chez moi, par contre sur la démo, il y a un soucis! /////

Arf... le soucis de la fonction realpath qui ne renvoi plus de / à la fin en php 5.2.5
L'archive est corrigée.

J'en reviens donc au problème cité plus haut...
Avec smarty, on ne peut pas utiliser un chemin relatif pour un set_filename.
Du coup, on est obligé de faire ca:

$template->set_filenames(array('plugin_admin_content' => rtrim(realpath(LOCALEDIT_PATH), '\\/') . '/admin.tpl'));

C'est pas le top, non?

Dernière modification par P@t (2008-02-29 20:35:54)

rvelices a écrit:

C'est pas plus simple de faire dirname(__FILE__)/admin.tpl pour obtenir un chemin absolu ?
Sinon effectivement - le chemin relatif est maintenant toujours par rapport au repertoire theme.

Oui, en effet, ca marche aussi...
Mais ca me chagrine un peu de ne pas pouvoir utiliser un chemin relatif...

Pourquoi ne pas rajouter dans la fonction set_filenames un truc du genre:

if (preg_match('/^[a-z_][^:]/i', $filename) )
{
   $filename = $this->root.'/'.$filename;
}

Comme pour l'ancien template... ;-)

Dernière modification par P@t (2008-02-29 20:54:06)

rvelices a écrit:

ddtddt a écrit:

S'il y en a un "facile" je veux bien regarder !

admin/group_perm et/ou admin/group_list ?

je regarde c'est 2 là

rvelices a écrit:

on peut le faire, mais dans l'ancien template assign( './admin.tpl' ) et assign( 'admin.tpl' ) ont 2 resultats differents: le premier est par rapport au script php d'origine et le 2eme par rapport au repertoire template.

Exactement ;-)
Et cela me parait etre une excellente solution!
C'est possible docteur?

(Bonjour à tous, longue absence, désolé, tout ça, merci à Mathias de m'avoir notifié de la discussion)

J'ai le sentiment qu'au point où nous en sommes, la discussion n'est plus "doit on passer à un moteur de template plus puissant ?" ni même "quel moteur de template plus puissant choisit-on ?" mais bien "en route vers Smarty".

Comme le dit mathiasm, j'ai passé PEM sur jTpl mi-2006 et c'est largement mieux que ce qu'il y avait avant. J'aurais pu passer au même moteur que PWG, mais j'avais envie de tester autre chose. J'aime bien jTpl, j'aime le confort qu'il apporte par rapport au moteur utilisé dans PWG. Comme dit rvelices, si on est d'accord avec jTpl, on est d'accord avec Smarty (et vice-versa). En effet, ils sont tous les 2 basés sur le même principe de fonctionnement, peut-être que Smarty sépare encore davantage la logique de présentation en limitant le nombre de fonctions accessibles. Bref, c'est plutôt un détail pour moi.

Smarty a l'énorme avantage d'être connu et donc de potentiellement attirer des développeurs (de plugin par exemple). Smarty a l'inconvénient d'être devenu une petite usine à gaz. C'est ce point qui pourrait me contrarier en terme de performances.

rvelices, ce qui serait intéressant, ce serait d'avoir une idée de la perte de performances entre une 1.7.1 et une Butterfly sur picture.php et index.php, les 2 pages principales.

En tout cas, on va dans le bon sens. Si cette discussion revient aujourd'hui, c'est qu'on ressent plus que jamais les limitations du moteur de template actuel (devrais-je déjà dire "l'ancien" ?). Merci rvelices d'être à nouveau "moteur" sur ce projet :-)

rub a écrit:

Par rapport au commit 2231, on ne devrait pas "ne pas toucher" à la partie smarty pour faciliter l'intégration de leurs nouvelles versions?

Oui, oui - mais comme on fait parfois les choses a notre sauce differente de smarty - je voulais juste avoir les infos de debugging sur les perfs... Mais t'as parfaitement raison sur le fond...

rub a écrit:

Et concernant le TAG_INPUT_ENABLED (c'est vrai que le page_header est mieux placé maintenant dans l'admin), pour éviter de la déclarer 2 dois (dans admin.php et page_header.php), on ne pourrait pas l'inclure dans la class template?
Soit avec un assign dans le constructeur comme pour themeconf?
Soit par l'ajout d'une fonction comme pour @translate?
Soit autrement?

Peut etre dans la classe template comme ROOT_URL ?