Templates

Evolutions autour du moteur de templates, sans pour autant en changer.

En très bref:

• Si je suis débutant: pourquoi être obligé de plonger aussi dans les css de l’admin...
• Si je suis débutant: comment me faire un tpl de test (rien que pour moi, sans mettre en péril ma galerie)? Pas le template au complet...
• Si je commence à avoir 5 ou 6 tpl à moi: pourquoi dupliquer le template? Au grand complet? Est-ce utile?
• Si je suis un peu avancé et que je veux faire mon template, pourquoi dupliquer les templates l’admin qui lui va évoluer et que je ne saurais pas forcément maintenir...?
• etc.

Bugs connus à l’heure actuelle: 421 426 430

Idées majeures des évolutions envisagées:

• Renforcer l’indépendance de la couche de présentation,
• Simplifier encore et encore
• Assouplir le processus
• sans tomber dans l’usine à gaz.

1 - Un php (pouvant ne pas exister) dans le template offre la possibilité (via une fonction?) de déterminer le lien entre une fonction de présentation (afficher le menu par exemple) et le fichier TPL correspondant en incluant son chemin.
exemples d’intérêt:

• Les guests ont un menu réduit, les membres ont un menu plus étoffé.
• Le template “Titi” utilise les tpl de yoga pour les fonctions x ou y.

Niveau: Pas très compliqué: très souple.

En résumé: par exemple si je veux afficher un écran de personnalisation sans le choix de template et ceci sans toucher à profile.tpl, je pourrais le faire et cela sera simple, facile et recommandé.

2 - Le “pulling” d’informations... Aujourd’hui on ne fonctionne qu’en mode push cad. que les php préparent de l’info pour les templates, ces infos sont affichées par le moteur... Activer le mode push pourrait s’écrire {local(my_function())}.
exemple: Un script externe renvoit des balises prêtes à être affichées... Météo ou autre.

Niveau: Juste un peu compliqué, mais presque déjà en place.

En résumé: Ce qu’on ne pouvait pas faire avec les tpl va fonctionner.

3 - La modularité: picture.tpl est composé de {element_top.tpl} de {element.tpl} de {prev_element.tpl} de {next_element.tpl} de {element_bottom.tpl} de {element_comments.tpl}
Libre à chacun ensuite d’assembler ses pièces comme un légo.

Conséquences : sur les galeries actuelles...

Niveau: un peu plus complexe qu’actuellement.

En résumé: l’ordre sera libre à chacun de faire ses choix.

4 - Template-common pourrait accueillir l’admin dans son ensemble pour éviter une duplication inutile et risquée.

Cela n’empêche pas le thème. Une $conf peut fixer le thème au besoin éliminant ainsi inaccessibilité de l’admin en cas d’erreur (rarissime au demeurant).

Niveau: complexe à mettre en oeuvre mais jouable.

En résumé: souple, simple et sécure.

5 - Les plugins peuvent livrer leurs tpls mais si la “fonction de présentation” existe dans le template actif, c’est le tpl correspondant qui serait utilisé. Ils ne doivent pas substituer leur tpl à un tpl existant, les plugins apportent des fonctionnalités mais n’altèrent pas la couche de présentation.

exemple: un tool-bar.tpl pour le bbCode dans les commentaires, la fonction est définie par le plugin comme étant bbToolC. Si bbToolC est une fonction connue du template actif... c’est le tpl donné par la fonction (Cf. 1) qui sera utilisé. Avec ça, le webmaster mettra les icones qui lui conviendront.

Niveau: marche avec le 1. super simple.

En résumé: J’installe un plugin, il utilise son tpl. Je fais ma version du tpl, le plugin utilise mon tpl.

6 - Se libérer des contraintes de l’upgrade sur les templates. template-extension pourrait être rebaptisé local-template et contenir uniquement les tpl de substitution ou complémentaires des templates actifs.

exemples:
template-common/local-layout serait transféré dans local-template/layout.css
template/yoga/local-layout.css serait transféré dans local-template/yoga/layout.css
local-template/yoga/footer.tpl pourrait être redéfini ici (cf. point 1) ⇒ plus de perte en cas d’upgrade.

Niveau: Super simple et marche encore avec le 1.

En résumé: moins de risque d’erreur.

7 - Léger redécoupage des TPL... Les TPL ne devrait pas fermer les balises de son dernier bloc (paramètre à gérer) afin de permettre aux plugins de s’incruster... L’idée doit encore faire son chemin mais le principe est jouable.

Niveau: plus complexe que cela en a l’air.

En résumé: plus de possibilités.

8 - Le tpl en php (.tpl.php). En option pour utilisateurs très avancés... (Une idée à justifier et à expliquer avant que cela marche). Le .tpl.php est d’abord appelé en tant que php, il retourne dans une variable globale un flux tpl qui serait parsé par le moteur. Evidemment ce type de template est mixable avec le reste.

Niveau: pas excessivement compliqué.

En résumé: totalement libre à la créativité mais il faudra coder.

9 - Si le .tpl.php ne marche pas, envisager sans changer de moteur d’intégrer du conditionnel.

Niveau: assez complexe.

...

• (à déterminer) initialement prévue pour la branche 1.8

• Parlons des templates

• L'en-tête
• ...