Squelettes SPIP à layout unique Exemple du squelette Zesty

, par Matthieu Marcillaud

| 5

Les possibilités de SPIP 2.0 permettent, grâce - entre autre - au critère {env}, d’écrire des jeux de squelettes dont la structure HTML est indiquée dans un unique fichier.

Historique

Des squelettes pour SPIP 1.9 avaient déjà une structure proche ; c’est le cas de SPIP Clear.

SPIP 2.0 a introduit un critère nommé « env » qui permet de passer tout l’environnement d’un squelette à un autre.

Dans l’article l’après SPIP 2.0 Cédric propose de modifier les squelettes fournis avec SPIP pour utiliser...

Le critère ENV

Le critère {env} transmet toutes les informations d’environnement d’un squelette à un autre.

Si un squelette X.html reçoit les informations « id_rubrique », « id_article » et « lang », alors il peut inclure un autre squelette en transmettant ces paramètres de la sorte :

Avec le critère {env}, cela donne, pour le même comportement :

Avantages :

  • écriture plus courte !
  • tout est transmis : pas besoin de réfléchir !
  • la pagination fonctionne (pas besoin de {self=#SELF}

Inconvénient :

  • tout est transmis ! Ainsi, si des paramètres sont inutiles au squelette qui est appelé, il y aura quand même un cache spécifique de créé si ce paramètre inutile varie. Si on appelle : ?page=X&id_article=3&id_mot=5 dans l’URL, le paramètre id_mot, d’après la première écriture est inutile à l’inclusion. Pourtant, avec le critère {env}, il y aura autant de caches générés que de variation de la valeur de id_mot.

Un gabarit de page définit une seule fois (layout unique)

Dans la distribution actuelle de SPIP 2.0, les squelettes par défaut (le répertoire squelettes-dist) contient pour chaque objet (article, rubrique, sommaire, mot...) une description des blocs HTML utilisés, sur la base de layout gala.

Pour une raison X ou Y, si quelqu’un veut modifier pour son squelette cette structure HTML - ce qu’on appelle souvent layout ou gabarit - il doit modifier tous les fichiers article.html, rubrique.html, mot.html... pour tenir compte de ce changement.

En fait, le code générant la structure HTML est dupliqué autant de fois qu’il y a de type de page sur le site.

On peut avec le critère {env} faire tout autrement pour ne conserver qu’un seul fichier générant la structure (une seule fois le code), pour peu qu’on ait un peu d’organisation !

Prenons plan.html et revisitons le. Il va simplement inclure un fichier « pages/layout.html » (ou tout autre nom qui vous convient) en transmettant un argument en plus : le type de page appelé.

Le fichier « layout.html » va utiliser ce paramètre supplémentaire pour appeler ensuite d’autres inclusions. Voyons à quoi il peut ressembler :

Quelques détails du fichier de structure

Ce fichier, dans cet exemple, définit le DOCTYPE des pages générées. Les méta-informations, entre les balises <head> et </head> sont ajoutées par deux inclusions : une inclusion générique quelque soit la page, via :

Cette inclusion ajoute par exemple les liens vers les fichiers CSS et vers la librairie jQuery à travers la balise #INSERT_HEAD.

Puis une inclusion spécifique en fonction du type de page demandé ajoute des informations particulières (souvent le titre et la description, parfois des Javascript supplémentaires). Le nom du fichier est calculé grâce à la balise #ENV{type} :

Cette seconde inclusion appelle donc, pour notre exemple, le fichier « pages/head/plan.html ». Il contient peu de chose :

Le reste n’a donc plus de secret : entre les balises <body> et </body> se trouve uniquement la structure HTML et des inclusions, de la même forme que dans le <head>.

Organisation des dossiers (squelette Zesty)

La page de structure du code HTML appelle un certain nombre d’inclusions. Elles sont rangées dans des sous répertoires préalablement choisis. Dans le cas de Zesty, on retrouve dans le répertoire pages/, les répertoires head/, navigation/ et contenu/ ce qui donne une arborescence comme ceci :

  • article.html
  • rubrique.html
  • ...
  • pages/
    • layout.html
    • head/
      • article.html
      • rubrique.html
      • ...
    • contenu/
      • article.html
      • rubrique.html
      • ...
    • navigation/
      • article.html
      • rubrique.html
      • ...

Cas particuliers des objets et des 404

SPIP appelle automatiquement la page 404 lorsqu’aucun contenu n’est généré par la page demandée. Dans le cas des articles par exemple, si l’on appelle directement le fichier de structure, un contenu HTML sera généré, même si aucun article n’est présent. Il faut donc conditionner l’inclusion de la structure à la présence de l’article, en la mettant dans une boucle. Il résulte un fichier article.html comme ceci :

De la même manière, la page 404 doit envoyer des entêtes particulières. Il suffit de les insérer avant l’appel de l’inclusion, ce qui donne pour le fichier 404.html :

De la simplicité des thèmes

Souvent lorsque l’on récupère un thème graphique sur internet, il n’a pas la même structure HTML que celui des squelettes SPIP d’origine. Avec cette organisation de fichiers, il est bien plus facile de s’adapter : on surcharge dans un plugin ou dans son dossier squelettes les fichiers « layout.html » et « habillage.css » et voilà !