rub a écrit:
Pour ca, il faut aussi activer le mode debug des templates avec MultiView!
ou $conf['debug_template'] := true;
On ne devrait pas le mettre à true dans le BSF et le changer lors de la livraison comme on fait d'habitude?
Hors ligne
rub a écrit:
VDigital a écrit:
Juste histoire de me faire la main...
Je livre l'adaptation smarty d'Admin Advices.
8-)
PS: svn 2266 (Petit coup d'oeil de rvelices) - Merci.Et alors, tu en penses quoi?
C'est compliqué, facile? Abordable pour tous?
Je donne mon avis.
Quand P@t me donne une solution d'écriture soit-disant plus simple, je dis non.
Cela à l'air plus simple mais on déporte de la logique fonctionnelle vers la couche présentation et là, tu le sais aussi bien que moi, c'est moins performant et une erreur de conception.
Ceci dit effectivement :
- dans la 1.8 dès que la séparation admin/galerie sera en place, coté admin. P@t va s'amuser avec les {html_checkboxes} et autres bidouilleries de Smarty.
- dans les exemples de nos plugins standards, il faut éviter les formes avancées (Modificateurs de variables complexes, et Fonctions utilisateur de Smarty qui soulèveraient plus de questions qu'elles n'apporteraient de réponses).
- après la livraison de la 1.8, un besoin ponctuel pourra être développé simplement en partant de la couche présentation et là l'exemple de P@t est exact.
Ce que j'apprécie le plus, par principe:
- {include file='menubar.tpl'}
- {ldelim},{rdelim} et {literal} qui nous seront utiles dans les tpl avec css, Javascript.
- register_modifier() et register_function() pour ce qui est des Méthodes mais là encore par ici lamonie et ah! bon essian.
8-)
Hors ligne
VDigital a écrit:
Cela à l'air plus simple mais on déporte de la logique fonctionnelle vers la couche présentation et là, tu le sais aussi bien que moi, c'est moins performant et une erreur de conception.
Ce n'est pas forcement moins performant car le traitement est soulagé du côté php (php: les boucles d'assign de tableaux sont remplacés par un simple tableau / tpl: on boucle une seule fois).
Et pas forcement un erreur de conception dans l'ancienne version des templates, le fait de tout mettre entre balise conditionné trop l'affichage.
Avec smarty, on en fait ce qu'on veut grace aux if et aux for.
Avec smarty, je pense aussi que c'est plus simple à comprendre qu'avant (dev ou pas).
Mais c'est vrai que c'est limite.
Sinon, je suis d'accord avec toi sur les autres points.
Hors ligne
Avec les données préparées dans le php parent...
- le cache et uniquement des {$variables}
cela sera forcément plus rapide avec des données non préparées (mais peut être pas visible) que:
- le cache et tout un tralala de {if}{elseif}{/if} qu'il faudra compiler et qui de toute façon seront à un niveau itératif inférieur donc pénalisant.
... mais peut être pas visible, sauf sur un mois de fonctionnement et au niveau de la conso du serveur.
Et reste, l'analyse des problèmes et erreurs, où là je n'ai pas assez de recul pour apprécier Smarty.
8-)
Hors ligne
VDigital a écrit:
cela sera forcément plus rapide avec des données non préparées (mais peut être pas visible) que:
- le cache et tout un tralala de {if}{elseif}{/if} qu'il faudra compiler et qui de toute façon seront à un niveau itératif inférieur donc pénalisant.
Vincent, je ne sais pas si t'as regarde l'ancien template, mais il compile aussi les tpl dans du code php (en memoire) et il execute apres ce php...
Hors ligne
rvelices a écrit:
Sinon c'est reparti pour les erreurs de user_list ... J'en ai un paquet. Un exemple est ADVISER_YES qui n'est pas sette dans le template ... (Notice: Undefined index: ADVISER_YES in D:\pwg\bsf\_data\templates_c\%%D1^D1A^D1A29EED%%user_list.tpl.php)
Heu... c'est normal, non?
Est-ce qu'il faut que toutes les variables du templates soient attribuées???
Ce n'était pas le cas avec l'ancien template...
Hors ligne
VDigital a écrit:
Je donne mon avis.
Quand P@t me donne une solution d'écriture soit-disant plus simple, je dis non.
Cela à l'air plus simple mais on déporte de la logique fonctionnelle vers la couche présentation et là, tu le sais aussi bien que moi, c'est moins performant et une erreur de conception.
Je suis pas tout à fait d'accord... je trouve que le gros avantage de smarty, c'est de pouvoir passer dans le template un tableau déjà tout fait...
Smarty s'occupe du reste... et je ne pense pas que cela surcharge le serveur...
Et je pense que cette méthode est un très bon exemple pour les développeurs de plugin... (vu qu'il s'agit ici d'un plugin!)
Dernière modification par P@t (2008-03-11 13:18:58)
Hors ligne
P@t a écrit:
rvelices a écrit:
Sinon c'est reparti pour les erreurs de user_list ... J'en ai un paquet. Un exemple est ADVISER_YES qui n'est pas sette dans le template ... (Notice: Undefined index: ADVISER_YES in D:\pwg\bsf\_data\templates_c\%%D1^D1A^D1A29EED%%user_list.tpl.php)
Heu... c'est normal, non?
Est-ce qu'il faut que toutes les variables du templates soient attribuées???
Ce n'était pas le cas avec l'ancien template...
En Smarty on peut le mettre a On, a Off ou les laisser tel que defini en php.ini. J'ai choisi le dernier cas car ca m'a beaucoup aide dans la migration d'avoir des erreurs quand les variables ne sont pas definies...
Personellement je suis pour le laisser comme caet s'assurer que toutes les verifs sont faites. Si vous voulez le mettre a Off, pas de probleme mais ca sera ainsi dans tout les cas (y compris conf[debug_template]=true)
EDIT: je rectifie - rub a raison les warnings sont la seulement si debug_template = true ...
Dernière modification par rvelices (2008-03-12 02:11:59)
Hors ligne
Je ne vois pas bien l'intéret de devoir définir toutes les variables d'un template...
Surtout pour une page comme user_list ou il y a un paquet de boutons radio à définir comme cochés ou non...
Personellement, je passerai bien cette option à off...
De toute facon, en mettant le $conf['debug_template'] à true, on a de toute facon popup qui s'ouvre pour smarty, non?
Hors ligne
P@t a écrit:
Personellement, je passerai bien cette option à off...
-1 pour moi.
Je pense que maintenant avec les if, les "checked" html intégrés dans le tpl, il n'est plus nécessaire de faire des variables non définies.
Hors ligne
VDigital a écrit:
Et reste, l'analyse des problèmes et erreurs, où là je n'ai pas assez de recul pour apprécier Smarty.
Un des fondamentaux, c'est aussi que mettre tout le code html dans les tpl... finis les </ BR>, nl2br, "checked=checked" dans le php du coeur, tout se fait dans le tpl!
Hors ligne
rub a écrit:
VDigital a écrit:
Et reste, l'analyse des problèmes et erreurs, où là je n'ai pas assez de recul pour apprécier Smarty.
Un des fondamentaux, c'est aussi que mettre tout le code html dans les tpl... finis les </ BR>, nl2br, "checked=checked" dans le php du coeur, tout se fait dans le tpl!
Tout à fait, on va faire la chasse et trouver des solutions au cas par cas.
Si possible plus aucune balise html (dont style=) dans le code de base php.
8-)
Hors ligne
VDigital a écrit:
Tout à fait, on va faire la chasse et trouver des solutions au cas par cas.
Si possible plus aucune balise html (dont style=) dans le code de base php.
Je crois qu'on devrait commencer par s'attaquer au fichier functions_html.inc.php...
On devrait pouvoir virer la plupart des fonctions de ce fichier...
Un exemple: pierrick a migré les tags de la partie admin...
On devrait supprimer la fonction get_html_tag_selection au profis d'un {html_checkboxes}
Hors ligne
Bonne idée, mais il faut finir la migration smarty avant non?
8-)
Hors ligne
+1
Et ca peut se faire avant même si tout n'est pas fini car ca n'utilise pas forcement le include!
Hors ligne