Accueil du site > Carnet de prairies > Semences SPIP > Squelettes SPIP à layout unique

Squelettes SPIP à layout unique

Exemple du squelette Zesty

samedi 27 juin 2009, par Matthieu Marcillaud

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 :

  1. <INCLURE{fond=pages/entete}{id_rubrique}{id_article}{lang} />

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

  1. <INCLURE{fond=pages/entete}{env} />

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é.

  1. <INCLURE{fond=pages/layout}{env}{type=plan} />

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

  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  2. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="#LANG" lang="#LANG" dir="#LANG_DIR">
  3. <head>
  4. <INCLURE{fond=pages/inc-head} />
  5. <INCLURE{fond=pages/head/#ENV{type}}{env} />
  6. </head>
  7. <body class="page_#ENV{type}">
  8. <div id="page">
  9.         <div id="entete">
  10.                 <INCLURE{fond=pages/inc-entete} />
  11.         </div>
  12.        
  13.         <div id="conteneur">   
  14.                 <div id="contenu">
  15.                         <INCLURE{fond=pages/contenu/#ENV{type}}{env} />
  16.                 </div>
  17.                 <div id="navigation">
  18.                         <INCLURE{fond=pages/inc-navigation}{id_rubrique}{id_article} />
  19.                         <INCLURE{fond=pages/extra/#ENV{type}}{env} />
  20.                 </div>
  21.         </div>
  22.         <div id="pied">
  23.                 <INCLURE{fond=pages/inc-pied} />
  24.         </div>
  25.         #SPIP_CRON
  26. </div>
  27. </body>
  28. </html>
Télécharger

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 :

  1. <INCLURE{fond=pages/inc-head} />

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} :

  1. <INCLURE{fond=pages/head/#ENV{type}}{env} />

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

  1. <title><:plan_site:> - [(#NOM_SITE_SPIP|textebrut)]</title>
  2. [<meta name="description" content="(#DESCRIPTIF_SITE_SPIP|couper{150}|attribut_html)" />]
  3. <meta name="robots" content="none" />
Télécharger

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 :

  1. <BOUCLE_principale_article(ARTICLES){id_article}>
  2. <INCLURE{fond=pages/layout}{env}{type=article} />
  3. </BOUCLE_principale_article>
Télécharger

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 :

  1. #HTTP_HEADER{"HTTP/1.0 404 Not Found"}
  2. #HTTP_HEADER{"Cache-Control: no-store, no-cache, must-revalidate"}
  3. #HTTP_HEADER{Pragma: no-cache}
  4. <INCLURE{fond=pages/layout}{env}{type=404} />
Télécharger

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à !

Documents joints

5 Messages de forum

  • Squelettes SPIP à layout unique Le 1er juillet 2009 à 14:43 , par francois

    Aprés avoir lu un article sur le sujet sur spipcontrib j’ai experimenté a peu prés la même organisation de fichier.
    Voila comment moi je me représente cette organisation.
    Au niveau zero du dossier squelettes on a un fichier .html pour chaque type de page du site et un dossier qui va contenir le contenu des pages, ici il s’appelle PAGE.
    Dans le dossier PAGE j’ai un dossier pour chaque zone du layout, par exemple "barre-droite" barr-gauche" "tete" ou "pied" ainsi qu’un fichier html "body-layout.html" qui contient le html nécessaire au placement des zone ainsi que des inclusions de "fond spip".
    Dans chaque dossier de zone de layout (pour rappel "tete" ou "pied" ou des trucs du genre)j’ai des fichiers qui portent le même nom que le type de page ou il apparaissent.
    conclusion:jusqu’ici je suis trés proche de ce que tu préconises.
    En revanche si un bout de code est commun à plusieurs types de page je le mets dans un fichier appelé commun.html. par exemple si le pied de page est commun à tout mes types de page(par exemple article rubrique...) je créé un fichier commun.html dans le dossier page/pied c’est a dire page/pied/commun.html et je modifie l’appel de fichier depuis body-layout.html.

    Pour les variantes, par exemple si le contenu d’un rubrique doit étre affiché d’une façon différente des autres rubriques je créé des "variante de zone" dont le nommage correspond à la syntaxe zone-variante.html .
    Voici un exemple : j’ai besoin qu’une rubrique s’affiche comme un blog plutôt que d’afficher le contenu de la balise #TEXTE de la rubrique.
    Pour être précis je veux que dans la zone "contenu" de mon layout les articles s’affichent comme des billets de blog.
    - je créé en plus de rubrique.html un fichier rubrique-blog.html dans page/contenu .
    - dans mon fichier layout dans la partie qui correspond à la zone "contenu" j’appelle

    <INCLURE{fond=pages/contenu/#ENV{type}|concat{/#GET{variante-contenu}}}} {env}>

    .

    Pour que le code fonctionne il faut que la page ou il est écrit calcule la variante à utiliser à minima comme ceci : #SETvariante-contenu, -blog .Rq : ici je ne détaille pas le mécanisme qui détermine la variante à utiliser tout dépend de ce qu’on veut faire.

    Merci de partager autant ! je regarderais dans le détail l’organisation du squelette zesty pour me faire une idée plus précise.

    Répondre à ce message

  • Squelettes SPIP à layout unique Le 6 juillet 2009 à 12:46 , par Maïeul

    Il me semble (comme je te l’ai dit à Avignon) que SPIP gère automatiquememnt le HTTP-HEADER 404 ... à vérifier

    Répondre à ce message

  • Squelettes SPIP à layout unique Le 17 juillet 2009 à 16:38 , par Fabrizo

    Il me semble qu’utiliser le critère env env pour inclure d’autres squelettes pose problème dans la mesure ou le cache n’ai plus utilisé. Par exemple dans cette balise on retrouve l’heure courante qui par nature varie.

    Néanmoins cela lance bien le débat sur la structure des squelettes et l’article est , comme d’habitude, réussi.

    Répondre à ce message

  • Squelettes SPIP à layout unique Le 12 novembre 2009 à 05:14 , par soon7

    Grâce à cette "refactorisation", je pense qu’on va voir surgir beaucoup de thèmes de qualité, un peu à la wordpress.

    Le fait que tout le monde respecte la même structure en terme de fichiers et de code xhtml, ça va être super simple d’appliquer un jeu de squelettes.

    Franchement bravo ^^ !

    Répondre à ce message

  • Squelettes SPIP à layout unique Le 17 décembre 2009 à 15:31 , par soon7

    et par rapport aux surcharge ? ça permet de gérer eégalement article-Xen mettant head/article-X, contenu/article-X, etc ?

    Répondre à ce message

Répondre à cet article


Rubriques

Site réalisé avec SPIP • © 2001-2012 marcimat. Ma Graine .Net • Archives • RSS 2.0