Les templates

Fiche


Niveau de difficulté : Expert.
Recommandations : n/c.
A lire aussi : Les templates [Astuces]


Inspirez-vous aussi de ce qui existe déjà.

FIXME: La page est encore en élaboration au niveau des spécifications.
Si vous ne comprenez pas certains points : Le Topic du forum (lien en fin de page) est là pour ça.

Templates

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

Fonctionnalités existantes

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 le template “admin.tpl” qui lui va évoluer et que je ne saurais pas forcément maintenir… ?
  • etc.

Fonctionnalités souhaitées

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. Si 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 renvoi 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 Lego.

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 l'inaccessibilité de l'admin en cas d'erreur (rarissime au demeurant).

Niveau : complexe à mettre en œuvre 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 icônes 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 Le 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. Évidemment 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.

L'en-tête

C'est la partie du template commune à l'ensemble des pages chargée de produire le “haut” de la page HTML.

Il produit les éléments suivants :

  • Définition du type de document (DOCTYPE),
  • Ouverture du document (tag <html>),
  • En-tête du document HTML (tag <head>),
  • Ouverture du corps du document (tag <body>),
  • Éléments HTML communs en haut de page (bannière, etc.)

Implémentation

Dans le template, l'en-tête est dans le fichier header.tpl. Il est utilisé par le script include/page_header.php lui-même appelé (include) par tous les scripts générant une page HTML. (FIXME mettre en cohérence les deux noms de fichier)

L'appel de l'include doit se faire à la fin, juste avant de parser le template principal de la page afin de pouvoir utiliser toutes les variables intéressantes.

Exemple pour picture.php :

include(PHPWG_ROOT_PATH.'include/page_header.php');
$template->parse('picture');
include(PHPWG_ROOT_PATH.'include/page_tail.php');

Note : ce n'est pas respecté dans la plupart des cas dans PWG 1.6

Type de document

Le type de document (DOCTYPE) utilisé est HTML 4.01 strict :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Note : dans une discussion du forum yoDan expliquait l'intérêt de ce choix par rapport à XHTML 1.0 (en Anglais Improved HTML and layout)

Ouverture du document

L'en-tête est chargée d'ouvrir le tag <html> du document, de fixer la langue utilisée et la direction du texte selon les préférences de l'utilisateur.

En-tête HTML (''<head>'')

Déclaration du jeu de caractères

Le jeu de caractère est récupéré dans les informations de la langue utilisée et traité au niveau du protocole HTTP par la déclaration du Content-Type dans page_header.php, et au niveau du document HTML par un tag META http-equiv=“Content-Type”.

Note : Normalement le http-equiv devrait suffire, mais ce n'est pas le cas.

Le jeu de caractère utilisé actuellement (PWG 1.6) est iso8859-1 également appelé latin-1. Le jeu de caractère unicode (UTF8) se généralisant et permettant un meilleur support des caractères accentués et des caractères spéciaux, PWG doit basculer en UTF-8.

Impact sur les fichiers de langue, et probablement sur les informations IPTC récupérées des photos, ainsi que sur la base de données. FIXME : certains l'ont déjà réalisé sur leur galerie perso, retour d'expérience souhaité.

La migration des galeries existantes sera également un point à traiter.

Rafraichissement

Tag META http-equiv=“refresh” utilisé pour le mode diaporama.

Autre tags META

Les autres tags META de l'en-tête servent à donner de l'information sur le contenu du document HTML. Ils sont notamment utilisés par les robots et les moteurs de recherche.

Beaucoup de légendes circulent sur le rôle et l'utilité de ces tags. On se limitera à quelques uns qui semblent bien maîtrisés.

La valeur de ces tags sera différente suivant les pages :

tag Home Category Picture autres pages
robots “index, follow”
generator “Piwigo (aka PWG), see piwigo.org”
author FIXME : TBD FIXME : TBD Auteur N/A
keywords 20 mots clés les plus représentatifs de la galerie 20 mots clés les plus représentatifs de la catégorie mots clés de la photo N/A
description description de la galerie description de la catégorie description ed la photo N/A

Titre

Icone

[[v2:projet:developpement:en-tete_1]]

Liens de navigation

Ces liens sont utilisés par certains navigateurs (Opera, Mozilla, …) pour construire une barre de navigation. Ces liens pourraient également être utiles aux robots et moteurs de recherche. Il semble que les liens “next” et “prev” soient également utiles pour le préchargement des pages dans Mozilla (FIXME vérifier l'efficacité).

Ils sont déclarés dans un tag de la forme :

<link rel="___" title="___" href="___">

Ces liens sont utilisés dans les pages “picture” et leur contenu est repris de la barre de navigation affichée au dessus de la photo. Les types de liens définis dans les spécifications HTML 4.01 sont complétés par des types usuels et l'usage peut être un peut différent de l'interprétation stricte de la norme.

lien destination HTML 4.01 Commentaire
start x La définition de “start” dans HTML 4.01 suggère un usage équivalent à “first”, Opéra et Mozilla l'utilisent pour le bouton “Home”. top est un synonyme défini en HTML 3.2
first Première photo de la catégorie
prev Photo précédente x Synonyme “previous” pour certains navigateurs (Opera et Mozilla acceptent les deux)
next Photo suivante x
last Dernière photo de la catégorie
up Catégorie
searchPage de recherche Défini en HTML 3.2

Note : les liens prev et up devraient être implémentés avec un attribut rev au lieu de rel car il s'agit de liens de retour. Opera et Mozilla ne semblent pas les accepter (testé avec les version respectives 8.54 et 1.73).

Note : Une implémentation complète de la navigation demanderait de définir la même chose pour les catégories comme cela a été demandé dans une fiche d'évolution (FIXME : indiquer le numéro de fiche).

Le pied de page

Astuces

Voir la page : Les templates [Astuces]

 
Haut de page
projet/developpement/templates.txt · Dernière modification: 2010/05/03 11:32 par ddtddt
 
 
github twitter facebook google+ newsletter Faire un don Piwigo.org © 2002-2017 · Contact