La logique des paramètres SDX
Les actions (ou services) fournies par SDX montrent un gros besoin de paramètres. Une application SDX étant essentiellement une application serveur, on devine qu'il y a plusieurs sources possibles pour fixer ces paramètres. Reste à en définir précisément les priorités, afin qu'une page puisse s'appuyer sur cet ordre pour définir des logiques fines, bien que très économes en syntaxe. C'est ce que nous entendons éclairer dans cette section de la documentation.
Table 1. Priorité des paramètres par ordre décroissant[a]
Example 1. Priorité de définition des paramètres SDX
Un petit exemple introduira bien ces différences. Le code ci-dessous n'a besoin d'aucune transformation particulière pour être visible sur un navigateur (pourvu que la Sitemap soit correctement configurée).
<?xml version="1.0"?>
<xsp:page xmlns:xsp="http://apache.org/xsp">
<sdx:page xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx">
<html><head><title>SDX - paramètres</title></head><body>
<h1>Les paramètres SDX</h1>
<xsp:logic>
String java=null;
if (!"".equals(request.getParameter("java")))
java=request.getParameter("java");
</xsp:logic>
<div>
<sdx:executeSimpleQuery
query="sdxall:1"
querySession="cache"
queryParam="question"
queryString="java"/>
</div>
<textarea rows="10" col="80" style="width:100%">
<sdx:executeSimpleQuery
query="sdxall:1"
querySession="cache"
queryParam="question"
queryString="java"/>
</textarea>
<p>Pour tester l'ordre croissant
des priorités,
inscrivez des valeurs différentes
dans plusieurs champs.</p>
<form method="get">
<ol>
<li>
Un paramètre dans l'application @query="sdxall:1"
</li>
<li>
Une valeur en session=
<xsp:expr>session.getAttribute("cache")</xsp:expr>
</li>
<li>
Un paramètre d'application ?question=
<input name="question"/>
</li>
<li>
Une variable String java=
<input name="java"/>
</li>
<div>
<input type="submit"/>
</div>
</ol>
</form>
</body></html>
</sdx:page>
</xsp:page>
- Paramètre Java™ : nameString="variable_java"
-
L'action SDX prendra son paramètre de la variable Java™ indiquée (à condition qu'elle ne soit pas nulle). Attention ! Cette variable doit être de type java.lang.String.
Example 2. Utilisation de paramètre java™ dans la construction d'une requête
Le code XSP ci-dessous récupère la valeur recherchée et l'insère dans des guillemets doubles afin de forcer le moteur de recherche à travailler sur le groupe de valeurs précisemment (rechercher station inra, ne revient pas au même que de rechercher "station inra").
<?xml version="1.0"?>
<xsp:page xmlns:xsp="http://apache.org/xsp">
<sdx:page xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx">
<xsp:logic>
String fulltext = '"'+request.getParameterValues("query")+'"';
<sdx:executeSimpleQuery valueString="fulltext" />
</xsp:logic>
</sdx:page>
</xsp:page>
- Paramètre Java™ : nameStrings="variable_java[]"
-
L'action SDX prendra son paramètre du tableau de la variable Java™ indiquée (à condition qu'elle ne soit pas nulle). Attention ! Cette variable doit être de type java.lang.String.
Example 3. Utilisation de paramètre java™ dans la construction d'une requête
Le code XSP ci-dessous montre comment on peut filtrer dynamiquement une liste de termes recherchés afin d'alimenter une ListQuery. Une valeur peut ainsi être rejetée.
<?xml version="1.0"?>
<xsp:page xmlns:xsp="http://apache.org/xsp">
<sdx:page xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx">
<xsp:logic>
String[] typedocParam = request.getParameterValues("typedoc");
String[] typedocs = new String[typedocParam.length];
for(inti=0; i < typedocParam.length; i++){
if( !typedocParam[i].equals("une_mauvaise_valeur") )
typedocs[i] = typedocParam[i];
}
<sdx:executeListQuery field="typedoc" valueStrings="typedocs" />
</xsp:logic>
</sdx:page>
</xsp:page>
- Paramètre Sitemap : nameSitemap="nom spécifique"
-
Les paramètres Sitemap ont été développés depuis le version 2.1 de SDX. L'avantage d'utiliser un tel paramètre dans une application est qu'un paramètre Sitemap peut être dynamique (calculé à partir d'une URL comme le montre l'exemple ci-dessous) ou simplement statique (codée en dur dans la Sitemap).
Example 4. Paramètre Sitemap dynamique (TODO : Pas clair dans un contexte XSP)
Dans l'exemple suivant, on utilise la Sitemap pour retirer les paramètres nécessaires à l'exécution d'une action SDX :
sdx:includeDocument
. Le but est d'afficher un document préalablement indexé par une application SDX.
-
Le générateur document.xsp contenant l'action sdx:includeDocument ;
-
L'URL {serveur SDX}/sdxtest/docs/F19993315A26T2.xml ;
-
Le code de la Sitemap chargé de générer le contenu de l'URL :
<map:match pattern="*/*.xml">
<map:generate type="xsp" src="document.xsp">
<map:parameter name="base" value="{1}"/>
<map:parameter name="id" value="{2}"/>
</map:generate>
<map:serialize type="xml"/>
</map:match>
- Paramètre HTTP : nameParam="http_param"
-
Cet attribut indique que l'action arrête d'écouter le paramètre http par défaut (?name=value), pour désormais réagir à ?http_param=value.
- Paramètre session : nameSession="cle"
-
La force des interfaces web est qu'elle n'exigent pas de connexion continue avec le serveur. La conséquence, c'est le manque de persistance des informations d'une transaction à une autre. On peut passer un paramètre d'URL de page en page, mais cela devient très incommode pour le développeur d'application (comme pour l'utilisateur souhaitant garder des URLs pérennes). Un moteur de servlets tels que celui sous-jacent à SDX (i.e. Cocoon™) permet de garder une session pour chaque utilisateur connecté (i.e. une fenêtre de navigateur). Ce mécanisme est notamment employé par SDX pour conserver des informations comme l'identité de l'utilisateur ou les résultats de requêtes dans lesquels on désirera naviguer page par page.
Chaque application peut souhaiter fixer des valeurs persistantes au choix de l'utilisateur, comme le nombre de résultats par page, l'inclusion ou non de documents dans les résultats de recherche ; d'autant plus que la Sitemap Cocoon permet de résoudre une ressource en fonction de ces paramètres de session (matcher de session). L'utilisateur peut ainsi choisir et conserver une XSL de présentation en ayant actionné une et une seule fois un paramètre stocké désormais dans sa session. Le développeur d'applications saura imaginer d'autres options.
Lorsqu'un paramètre de type *Session="cle" est ajouté à une action (par exemple
sdx:executeSimpleQuery
), il indique que désormais toute valeur fournie par l'utilisateur (paramètre http) sera stockée dans l'objet de session cle. On a donc un comportement persistant de l'action, changeant à chaque nouvelle valeur donnée en paramètre utilisateur. (TODO : clarifier)
- Paramètre simple : name="valeur"
-
Valeur fixée par le développeur d'application.
- Paramètre SDX
-
Au mieux, SDX fournit le contexte nécessaire à l'exécution des actions par l'intermédiaire de valeurs par défaut codées en dur dans SDX. Ainsi pour exécuter une recherche, il n'est pas nécessaire de préciser l'application (app), SDX fournira l'identifiant de l'application courante dans app.
| 
Télécharger
Installer
Référence API-XSP
Paramètres SDX 
