Petite question...
J'essaye de passer LocalFiles Editor en smarty.
Problème: le set_filenames renvoit vers le dossier template/yoga obligatoirement.
Donc, à part mettre mon fichier tpl dedant, je fais comment?
EDIT: bon, j'ai réussi en utilisant un realpath(), mais c'est quand meme pas l'idéal.
Il faudrait pouvoir rentrer un chemin relatif à la racine de PWG (et non au dossier template)
EDIT2: je me suis déjà habitué en smarty en 1h!
J'ai regardé la doc, et ca m'a l'air tout simplement excellent!
Je sens que la création de plugins va etre encore plus facile avec toutes ces nouvelles fonctions.
EDIT3: je peux migrer le intro.tpl pour me faire la main?
Dernière modification par P@t (2008-02-28 15:28:03)
Hors ligne
rub, pour le site démo, voila le premier plugin smarty ;-)
LocalFiles Editor 1.8.beta
Il faudra que je pense à le commiter...
Hors ligne
P@t a écrit:
rub, pour le site démo, voila le premier plugin smarty ;-)
LocalFiles Editor 1.8.beta
Il faudra que je pense à le commiter...
Cool...
Peut-être que ce soir, car je mettrais à jour la BSF, il y aura peut-être ton nouveau commit! ;-)
Hors ligne
P@t a écrit:
Problème: le set_filenames renvoit vers le dossier template/yoga obligatoirement.
Donc, à part mettre mon fichier tpl dedant, je fais comment?
EDIT: bon, j'ai réussi en utilisant un realpath(), mais c'est quand meme pas l'idéal.
Il faudrait pouvoir rentrer un chemin relatif à la racine de PWG (et non au dossier template)
Un chemin absolu devrait marcher...
P@t a écrit:
EDIT3: je peux migrer le intro.tpl pour me faire la main?
Stp, stp, stp ...
Je prepare un gros commit sur picture.php + tpl associes. Merci de ne pas modifier si possible...
Hors ligne
Oui, le chemin absolue marche... avec la fonction realpath.
Mais si je met un chemin relatif (par exemple PHPWG_PLUGINS_PATH . 'monplugin/monfichier.tpl'), ca ne marche pas!
C'est pas bien grave, mais c'est quand meme dommage, vu que ca fonctionnait très bien avant.
Sinon, j'attend pour commiter une première migration ;-)
Hors ligne
Le sujet semblait intéressant sur la première page et puis finalement on tombe encore et encore dans les même travers du moteur de template usine à gaz qui compense ses manques et ses faiblesses par un cache.
Je ne retrouve pas les discussions d'il y a plusieurs années déjà où Pierrick et d'autres justifaient l'utilisation d'un moteur de template minimaliste. J'étais d'accord avec le principe.
Pour finir, si on fait plus qu'un simple affichage de chaîne de caractères ou de liste dans un template c'est qu'on mélange encore contrôleur, modèle et vue.
Hors ligne
nicolas a écrit:
Le sujet semblait intéressant sur la première page et puis finalement on tombe encore et encore dans les même travers du moteur de template usine à gaz qui compense ses manques et ses faiblesses par un cache.
Je ne retrouve pas les discussions d'il y a plusieurs années déjà où Pierrick et d'autres justifaient l'utilisation d'un moteur de template minimaliste. J'étais d'accord avec le principe.
Pour finir, si on fait plus qu'un simple affichage de chaîne de caractères ou de liste dans un template c'est qu'on mélange encore contrôleur, modèle et vue.
Je suis desole, mais je ne suis pas 100% d'accord. Oui il y a un risque de melange si on expose vers le template trop des choses (comme php par exemple). Mais le modele/controleur qui donne le nom de la classe css, ou encore qui gere les lignes et les colonnes des miniatures c'est aussi un melange. Je me suis retrouve plusieurs fois a vouloir faire de l'Ajax, mais avec le vieux template impossible a transformer une chaine de caracteres en javascript si elle contiens des ' ou ". Aussi impossible a sortir des block_vars imbriques imposes par le php.
PS. On n'utilise pas le cache de smarty (le cache est pour le resultat affiche par smarty), mais les templates "compiles".
Hors ligne
rvelices, dans mon commit 2226, j'ai passé les tabsheet en class et de ce fait, j'ai changé ce que tu avais commencé à implémenter avec le "{include file='admin/tabsheet.tpl'}".
Perso, je trouve un peu trop compliqué (dans le cas du tabsheet) de faire le include dans le tpl puis le assign "en dur" dans le php, la méthode par class me semble plus à comprendre et à utiliser.
Qu'en penses-tu?
J'ai donc pu tester vite fait smaty et c'est vrai que bien de pouvoir faire des for dans le template, ca permet de bien la différence entre l'utilisation et leur présentation.
Pour smarty, je suis de l'avis de rvelices et je trouve qu'avec on retrouve mieux le MVC.
Avec smarty, on a bien la vue qui recoit les donnés dénués de toutes présentations.
Dernière modification par rub (2008-02-29 00:52:23)
Hors ligne
P@t a écrit:
rub, pour le site démo, voila le premier plugin smarty ;-)
LocalFiles Editor 1.8.beta
Il faudra que je pense à le commiter...
Avec mon commit 2226, ta version ne doit plus être bonne à cause des tabsheets!
Hors ligne
rub a écrit:
rvelices, dans mon commit 2226, j'ai passé les tabsheet en class et de ce fait, j'ai changé ce que tu avais commencé à implémenter avec le "{include file='admin/tabsheet.tpl'}".
Perso, je trouve un peu trop compliqué (dans le cas du tabsheet) de faire le include dans le tpl puis le assign "en dur" dans le php, la méthode par class me semble plus à comprendre et à utiliser.
Qu'en penses-tu?
Pas de probleme pour le tabsheet. Neanmoins le include a un certain avantage dans d'autres cas: le fichier inclus est evalue en meme temps que le 'parent' donc pas de pb. des variables non definies au moment de faire assign_var_from_handle...
Hors ligne
Après picture, tu vas faire quoi?
Moi, je reste sur mes choix, P@t veut faire intro et toi?
Hors ligne
rub a écrit:
P@t a écrit:
rub, pour le site démo, voila le premier plugin smarty ;-)
LocalFiles Editor 1.8.beta
Il faudra que je pense à le commiter...Avec mon commit 2226, ta version ne doit plus être bonne à cause des tabsheets!
C'est bon, j'ai mis à jour l'archive...
J'essairai de faire un code propre et de commiter tout ca.
Hors ligne
S'il y en a un "facile" je veux bien regarder !
Hors ligne