  Documentation SDX-2 Télécharger Installer Présentation Configuration Indexation Recherche OAI Javadoc Référence API-XSP Pages XSP Paramètres SDX Vue d'ensemble Liste alphabétique Migration Schemas Performances | # Les pages XSP de Cocoon™ ## Préambule Cette page ne se substitue pas à une documentation de Cocoon™ (même si elle fait cruellement défaut en français !) ; seuls les principes permettant de comprendre une application SDX seront abordés dans cette section. Toutefois, les termes techniques employés seront généralement liés à une URL de référence (en anglais). ## XSP en quelques mots Tubes XML Une application SDX s'exécute dans le contexte de Cocoon™. Toutes les fonctionnalités de cet environnement y sont disponibles, en particulier, la définition d'un `sitemap.xmap`. Ce "plan du site" interprète les URLs demandées pour distribuer les ressources, selon un mécanisme astucieux et puissant, les pipelines ("tubes" ?). Inspiré d'Unix, ce concept rationalise les étapes d'un processus XML : génération d'une source, transformations successives, pour une sérialisation finale. Générateurs dynamiques Les services d'un serveur SDX (recherche et restitution de documents) sont accessibles de l'extérieur (grâce à des URLs pérennes), mais l'intérêt décisif commence à l'intérieur. On peut développer des logiques applicatives complexes avec les pages serveurs de Cocoon™ (XSP). Dans l'esprit des "tubes", XSP est un générateur d'événements XML. Plus classiquement, c'est un langage serveur. JSP ou PHP peuvent eux aussi être acceptés comme générateurs. Syntaxe XML Pourquoi avoir choisi ce "langage" plutôt que d'autres plus diffusés ? Parce ce qu'il s'agit d'un langage purement XML (comme XSL), directement inclus dans le coeur du document à générer. Les instructions sont identifiées par un namespace (`http://apache.org/xsp`). En contexte serveur, les éléments appartenant à cet espace de noms seront transformés en code Java™ (grâce à des filtres SAX), puis compilés dynamiquement (mécanisme similaire à JSP). Java™ Une page XSP devient donc une classe Java™. Ceci permet d'inclure facilement du code qui sera exécuté dans le contexte de cette classe (le fichier généré est à chercher dans le répertoire `work` de votre moteur de servlets). On a donc accès à un langage évolué, ainsi qu'à toutes les classes publiques disponibles dans l'environnement en cours. Une page dynamique XSP n'a donc pas besoin d'ajouter de librairie pour étendre son langage ; elle sert surtout à ouvrir Java™ à un contexte XML. Example 1. Récupération d'une variable Java™ dans une XSP Cette page XSP :
      <?xml version="1.0"?>
      <xsp:page xmlns:xsp="http://apache.org/xsp">
       <xsp:logic> java.util.Date today = new java.util.Date(); </xsp:logic>
       <document>
        <today>
         <xsp:attribute name="date">
          <xsp:expr>today</xsp:expr>
         <xsp:attribute>
        </today>
       </document>
      </xsp:page>
  donnera (si la Sitemap n'interpose aucune autre transformation) :
      <?xml version="1.0"?>
      <document>
       <today date="2001/10/04 14:35:34">
      </document>
  Page SDX SDX fonctionne à l'intérieur d'une page XSP, avec un son propre vocabulaire XML défini par un schéma. Les actions SDX sont elles aussi compilées, pour ouvrir tous les services du serveur. Soit la page suivante (la plus simple) :
      <xsp:page xmlns:xsp="http://apache.org/xsp">
       <sdx:page xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx"/>
      </xsp:page>
  Elle effectue de nombreuses opérations d'initialisation, et à la requête `{serveur SDX}/sdxworld/test.xsp?parametre=château+fort` elle générera avant transformation :
      <sdx:document
       xmlns:xsp="http://apache.org/xsp"
       xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx"
       xml:lang="fr-FR"
       server="http://localhost:8080/sdx"
       api-url="http://localhost:8080/sdx/sdx/api-url"
       app="fr.gouv.culture.sdx.sdxworld"
       uri="http://localhost:8080/sdx/sdxworld/test.xsp"
       query="?parametre=valeur"
       date="Thu Oct 31 13:14:13 CET 2002">

       <sdx:user anonymous="true"/>

       <sdx:parameters>
        <sdx:parameter
         type="get"
         name="parametre"
         value="château fort"
         escapedValue="ch%E2teau+fort"
        />
       </sdx:parameters>

      </sdx:document>
Document SDX Avant toute opération sur des bases de documents, une page SDX apporte de l'information contextuelle, parfois très utile aux transformations ultérieures (notez par exemple la liste des paramètres passés en URL, avec leurs valeurs claires ou encodées qui permettent par exemple de construire des URLs valides). Tous les éléments renvoyés par SDX sont eux aussi arrêtés par un schéma. ## Les bibliothèques de balises ## Transformation logique Ces bibliothèques de balises sont obtenues par une transformation préalable de la page XSP, avant qu'elle soit compilée. On conçoit que l'on peut ainsi factoriser et partager du code souvent utilisé, sans avoir à le recopier dans toutes les pages XSP qui en ont besoin. Par exemple, supposons que dans une application plusieurs pages XSP aient besoin d'inclure la date présente. On voudrait que cette information s'insère à l'endroit désiré du document destination, avec par exemple un élément `<my:date/>`. La définition précise d'un espace de noms évite le risque de confusions lors de transformations multiples. Une page XSP pourrait avoir le code suivant :
    <?xml version="1.0"?>
    <?xml-logicsheet href="logicsheet-my.xsl"?>
    <xsp:page xmlns:xsp="http://apache.org/xsp" xmlns:my="my">
     <document>
      <my:date/>
     </document>
    </xsp:page>
Il est fait appel ici à une transformation XSL `logicsheet-my.xsl` qui s'effectuera avant la compilation de la page. Cette feuille logique se conçoit comme une transformation d'identité, qui intercepte certains noms pour les remplacer. Exemple :
    ...
    <xsl:template match="my:date" xmlns:my="my">
     <xsp:logic> java.util.Date today = new java.util.Date(); </xsp:logic>
     <today>
      <xsp:attribute name="date">
       <xsp:expr>today</xsp:expr>
      <xsp:attribute>
     </today>
    </xsl:template>
    ...
Avant compilation, la page XSP ressemblera fort à l'exemple précédent et sa sortie sera identique. ## La feuille logique SDX L'interface XSP de SDX résulte d'une telle feuille. Ce fichier est livré dans l'archive `sdx*.jar`, que l'on trouve dans le répertoire `sdx/WEB-INF/lib` de la distribution. On peut l'extraire avec un utilitaire ZIP (ou le programme `jar` du JDK Java™), en la cherchant dans l'arborescence `fr/gouv/culture/sdx/logicsheet/sdx.xsl` ou dans les fichiers qu'elle importe, situés dans le même arborescence. Cocoon™ comporte déjà de nombreuses feuilles logiques prédéfinies dans le fichier de configuration `sdx/WEB-INF/cocoon.xconf` (la plupart des générateurs). Par défaut, la bibliothèque SDX est accessible par la déclaration suivante :
    ...
    <target-language name="java">
     <!-- Defines the XSP Core logicsheet for the Java language -->
     <parameter
      name="core-logicsheet"
      value="resource://org/apache/cocoon/components/language/markup/xsp/java/xsp.xsl"/>
     <!-- The SDX logicsheet. The XSLT file is in the SDX jar. -->
     <builtin-logicsheet>
      <parameter
        name="prefix"
        value="sdx"
      />
      <parameter
        name="uri"
        value="http://www.culture.gouv.fr/ns/sdx/sdx"
      />
      <parameter
        name="href"
        value="resource://fr/gouv/culture/sdx/logicsheet/sdx.xsl"
      />
     </builtin-logicsheet>
    </target-language>
SDX ne vous suffit plus ? Vous pouvez l'étendre ou développer vos propres feuilles logiques.
| Auteurs : Martin Sévigny ( AJLSM ) ; Frédéric Glorieux ( AJLSM ) ; Malo Pichot ( AJLSM ) - 2003-06-04

| Home |
Copyright © 2000, 2001, 2002, 2003, 2004 Ministère de la culture et de la communication, AJLSM.