Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Si vous vous posez une question, vous n'êtes peut-être pas le premier...Les traductions en français des bibles XML.Ces articles sont des références dans leur domaine.Tout ce qu'il faut savoir pour démarrer sur un sujet XML...


Feuilles de styles sans style.

Comment séparer présentation et logique tout en utilisant XSLT ?

Eric van der Vlist, Dyomedea (vdv@dyomedea.com).
jeudi 14 décembre 2000

Cet article a été publié sur XML.com sous le titre "Style Free XSLT Stylesheets" et a fait l'objet de présentations au Forum XML 2000 et à XML 2000.

Introduction

L'un des points marquants de XML les plus fréquemment mis en avant est sans doute la séparation entre contenu et présentation que l'on peut obtenir en appliquant des feuilles de style CSS ou XSL sur des documents XML.

Depuis les premiers travaux effectués sur XSL, les objectifs ont cependant évolué de manière radicale au point de donner naissance à un langage de transformation, XSLT, qui bien que ne présentant aucune fonctionnalité de formatage est beaucoup plus utilisé pour définir la présentation de documents que son demi-frère XSL Formatting Objects dont c'est pourtant la vocation.

Cette utilisation d'un langage de transformation pour formater des documents conduit à mélanger logique de transformation et informations de présentation.

Dotées de plus en plus de logique, les feuilles de style XSLT de sites complexes et notamment des portails Internet deviennent comparables à des programmes.

Conserver les informations de style dans ces feuilles de style présente donc les mêmes inconvénients que le stockage de données au sein de programmes: perte de souplesse et manque de maintenabilité, seuls les programmeurs pouvant les modifier.

L'utilisation croissance de technologies de pseudo-compilation au sein de servlets, et l'annonce de compilateurs de feuille de style XSLT vient renforcer cette tendance des feuilles de style à se comporter comme de véritables programmes et la nécessité de minimiser la quantité de données de présentation qu'elles contiennent.

Les outils de conception utilisés par les infographistes ne supportant pas XSLT, l'inclusion d'éléments de style dans les feuilles XSLT pose également des problèmes d'organisation au sein des équipes de création et de maintenance de sites Internet.

Un exemple simple.

Prenons un exemple simple pour illustrer notre propos.

Pour notre nouveau site portail utilisant un servlet XSLT  Java, nous devons produire une page d'accueil constituée de trois zones: deux d'entre elles, l'entête et les titres, sont communes à toutes les pages du site et seule la zone principale est spécifique à notre page d'accueil.

La structure du document que nous voulons produire est donc une table de trois cellules dont deux cellules seront génériques et une cellule spécifique à chacune des pages.

La solution traditionnelle.

La solution couramment utilisée pour aboutir à ce résultat au moyen d'une transformationXSLTest le placer la structure de la page dans la feuille de style elle-même:

<xsl:template match="/">
 <html> <head>
   <!-- Get the head values here... -->
   <xsl:apply-templates select="/html/head/*" /> </head>
 <body>   <table width="100%" border="1" bgcolor="LemonChiffon">
     <tr>
       <td colspan="2" width="100%">
       <h1>Header</h1>
       (common to every page of the site)</td>
     </tr>
     <tr height="300" valign="top">
       <td width="75%" bgcolor="Aqua">
           <!-- Get the body here -->
           <xsl:apply-templates select="/html/body/*"/>
      </td>
       <td width="25%">
       <h1>Headlines</h1>
       (common to every page of the site)</td>
     </tr>
   </table>
 </body>
</html>
</xsl:template>

On voit que la structure du document est directement insérée dans la feuille de style dans un élément xsl:template et que les données et bien souvent quelques éléments de présentation sont extraits du document source pour être insérés dans cette structure.

Nous pouvons donc résumer ainsi la situation dans laquelle nous nous trouvons:

source.xml + style.xslt -> page.htmldocument XML (données 50% + présentation 50%) + feuille XSLT (logique 50% + présentation 50%) -> (X)HTML page.

Première étape: sortons la présentation de la feuille XSLT.

Concentrons-nous d'abord sur la feuille XSLT et voyons comment nous pouvons séparer logique et présentation.

La manière la plus simple d'y parvenir est de placer la structure du document que nous voulons générer dans un document XHTML. On ajoutera simplement quelques éléments spécifiques –qui peuvent faire partie d'un autre espace de noms, bien que ce ne soit pas indispensable- pour contrôler les emplacements où l'on souhaitera insérer des éléments variables.

Dans notre cas, ce document XHTML (appelons le layout.xml) qui pourrait avoir été créé par un infographiste pourrait être:

<html>
<head>
   <insert-head/>
</head>
<body>
   <table width="100%" border="1" bgcolor="LemonChiffon">
       <tr>
           <td colspan="2" width="100%">
               <h1>Header</h1>
               (common to every page of the site)
           </td>
       </tr>
       <tr height="300" valign="top">
       <td width="75%" bgcolor="Aqua">
           <insert-body/>
       </td>
       <td width="25%"><h1>Headlines</h1>
       (common to every page of the site)</td>
       </tr>
   </table>
</body>
</html>

On notera les deux éléments de contrôle : <insert-head/> et <insert-body/> que la transformation XSLT va remplacer par les informations extraites du document source.

La feuille XSLT qui gèrera ce document (que l'on appelera logic.xslt) devient:

 <?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:variable name="page" select="/"/>
<xsl:variable name="layout" select="document('layout.xml')"/>
 <xsl:template match="/">
   <xsl:apply-templates select="$layout/html"/>
</xsl:template>
 <xsl:template match="insert-head">
   <!-- Get the head values here... -->
   <xsl:apply-templates select="$page/html/head/*"/>
</xsl:template>
 <xsl:template match="insert-body">
   <!-- Get the body here -->
   <xsl:apply-templates select="$page/html/body/*"/>
</xsl:template>
 <!-- Identity transformation -->
<xsl:template match="@*|*">
   <xsl:copy>
       <xsl:apply-templates select="@*|node()"/>
   </xsl:copy>
</xsl:template>
 </xsl:stylesheet>
 

Loin de compliquer la conception de la feuille XSLT, cette opération a au contraire permis de la "modulariser" et d'extraire la logique de la structure de la page.

Le template <xsl:template match="insert-body"> qui sera appelé lorsque l'on rencontrera l'élément < insert-body/> dans le fichier layout devient en effet un module que l'on peut utiliser ailleurs si nécessaire.

La seule astuce qui est mise en oeuvre ici est l'analyse initiale du document layout.xml (<xsl:apply-templates select="$layout/html"/>) et l'utilisation des éléments <insert-head/> et <insert-body/> pour "rendre la main" à la transformation XSLT et revenir au document source. Noter également la mémorisation du document source initial dans une variable globale (<xsl:variable name="page" select="/"/>) pour pouvoir extraire des informations de ce document après avoir analysé le document layout.xml (par l'instruction <xsl:apply-templates select="$layout/html"/>). C'est ce problème de sauvegarde de l'environnement et notamment du nœud contexte qui va nous empêcher répéter cette opération de manière récursive puisque XSLT est un langage sans effet de bord qui ne permet pas de modifier la valeur de ses variables.

En pratique, on sera donc amené à conserver quelques éléments de présentation dans la feuille XSLT, mais l'utilisation de ce fichier "layout.xml" permet de limiter fortement le phénomène et d'arriver à une situation du type:

source.xml + logic.xslt + layout.xml (lu par logic.xslt) -> page.html

Document XML (données 50% data + présentation 50%) + présentation générique XML (présentation 100%) + feuille XSLT (logique 90% + présentation 10%) -> (X)HTML

Deuxième étape: enlevons la présentation du document source

Notre document source est toujours un document XHTML qui contient donc à la fois des balises de présentation et des données.

C'est une situation qui ne permet pas de tirer partie de la séparation entre données et présentation.

Pour aller plus loin dans cette direction, il suffit de répéter la technique utilisée avec nos feuilles de style et de diviser notre document source en deux documents : un document qui contiendra la structure XHTML spécifique à notre page (qui sera insérée dans le cadre générique) et un document XML contenant des données pures.

L'insertion des données formatées dans la structure XHTML sera effectuée par la transformation XSLT en utilisant des balises spécifiques comme nous l'avons fait avec la feuille XSLT.

Ce type de composition à plusieurs niveau (une structure générique qui pilote l'insertion de structures spécifiques qui déclenchent l'insertion de données formatées) est très souple pour construire des sites de type portails dans lesquels sont fédérées des informations provenant de sources multiples qui sont agencées suivant une structure commune.

Les balises spécifiques utilisées pour déclencher les insertions d'informations peuvent communiquer des informations à la feuille de style au moyen de leurs attributs ou sous éléments et constituer une bibliothèque d'objets XHTML que l'on utilisera pour la composition des différentes pages.

Une balise permettant l'inclusion de titres d'informations au format RSS pourra par exemple s'écrire:

<document-rss src="decid/channel.xml" max-size="140"
   max-items="10" class="highlight"/>

que la feuille XSLT pourra interpréter comme une demande d'insérer les titre contenus dans decid/channel.xml en tronquant les descriptions à 140 caractères, limitant le nombre de titres à 10 et en utilisant un attribut "classe" égal à "highlight".

Si nous reprenons notre exemple et le complétons pour rajouter quelques fonctions courantes, nous pourrons donc avoir un fichier source, que nous appellerons maintenant "spec_layout.xml" contenant:

 <?xml version="1.0" encoding="utf-8"?>
<!-- This file is describing the layout of the specific
    part of the page.-->
<html>
  <head>
   <title>My page</title>
   <meta name="title" content="My page" />
   <meta name="description" content="Welcome on my new page" />
 </head>
 <body>
   <insert-body-header href="content.xml"/>
   <table width="100%" border="1">
       <tr valign="top">
           <td height="250">
           <insert-first-part href="content.xml"/>
       </td>
       <td >
           <insert-second-part href="content.xml"/>
       </td>
       </tr>
   </table>
 </body>
</html>

Nous avons isolé la structure spécifique de cette page et inséré des éléments de contrôle que la transformation XSLT va remplacer par un contenu extrait d'autres documents XML (ici,  content.xml) qui pourront être produits par une autre équipe.

Nous avons donc atteint une situation dans laquelle:

spec_layout.xml + content.xml + layout.xml+ logic2.xslt -> page.html

Structure XML spécifique (données 10% + présentation 90%) + données XML (présentation 10% + données 90%) + structure générique (présentation 100%) + feuille XSLT (logique 90% + présentation 10%) -> (X)HTML.

Et nous avons séparé nos informations entre:

  • Présentation (isolée dans des documentsXHTMLéditables avec des outils (X)HTML classiques et intégrant des balises spécifiques).
  • Logique stockée dans des feuilles XSLT mises au point par des développeurs.
  • Contenu stocké dans des sources de données XML alimentées par des rédacteurs.
Exemples réels

<XML>fr et 4xt sont tous deux construits en utilisant cette technique. Le source complet de 4xt peut être téléchargé sur le site (http://4xt.org/4xt.gz).

Copyright 2000, Eric van der Vlist.


 

Mots clés.



L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.


Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org