Les pages XSP de Cocoon™

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.

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.

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

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.

 
<?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>
		

<?xml version="1.0"?>
<document>
 <today date="2001/10/04 14:35:34">
</document>

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>

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.