Re: [sdx-users] qid multi-session

[Frédéric Glorieux]

> [URL app/base/docid]

> Il s'agit plus de développement cocoon que SDX. Ci-joint un exemple qui 
> a marché dans sdxtest, très commenté, c'est une idée parmi d'autres 
> d'implantation. S'il y a en plus des liens inter documents (ne serait-ce 
> que précédent|suivant), cela améliore sérieusement les résultats dans 
> google.

Désolé, je m'aperçois que le fichier que j'avais attaché n'était pas le 
bon. Je vous le met en texte, pour être sûr de ce qu'il y a

<?xml version="1.0"?>
<!--
Cette page sera appelée get.xsp, c'est presque une copie de "document.xsp"
de l'application sdxtest.

Elle illustre comment obtenir un document SDX selon des urls du genre
.../app/base/docid
Ceci repose sur le sitemap cocoon.
L'URL demandée y est analysée,
ces parties peuvent être passées à l'xsp sous forme de paramètres.

fragment de sitemap utilisant cette page

<map:match pattern="*/*.xml">
    <map:generate type="xsp" src="get.xsp">
      <map:parameter name="base" value="{1}"/>
      <map:parameter name="docid" value="{2}"/>
    </map:generate>
    <map:serialize type="xml"/>
</map:match>

Ceci signifie que l'appel initial produit du XML.
Utile au déboguage, en transformation xsl client, disponible
pour d'autres serveurs, il y a beaucoup de bonnes raisons.
Ici nous passons des membres de l'URL relative comme base et
docid

<map:match pattern="*/*.xml">
    <map:generate type="xsp" src="get.xsp">
      <map:parameter name="base" value="{1}"/>
      <map:parameter name="docid" value="{2}"/>
    </map:generate>
    <map:serialize type="xml"/>
</map:match>

Pour avoir du HTML, on peut utiliser un pipeline de ce genre
(conforme à l'architecture habituelle d'une application SDX)

<map:match pattern="*/*.html">
        <map:generate type="file" src="cocoon:/{1}/{2}.xml"/>
        <map:transform src="xsl/document.xsl"/>
        <map:serialize type="html"/>
</map:match>

Le pseudo-protocol cocoon:/ indique qu'il faut chercher dans ce
sitemap le pipeline qui traite la requête **.xml
(le fragment au dessus). Là-dessus vous appliquez par exemple l'xsl de
navigation de vos documents.
-->
<xsp:page language="java" xmlns:xsp="http://apache.org/xsp"; 
xmlns:sdx="http://www.culture.gouv.fr/ns/sdx/sdx";>
    <sdx:page>
        <bar/>
<!--
  A chaque page XSP, Cocoon fournit l'objet parameters, dans lequel
  on trouve les paramètres passés par le sitemap.
  On les récupère ici, pour les passer à la requête SDX.
-->
<xsp:logic>
                String base=parameters.getParameter("base");
                String docid=parameters.getParameter("docid");
</xsp:logic>

<!--
  Ceci est un petit snippet pour voir ce qu'il y a dans les
  paramètres. Toujours utile en déboguage.
-->
<xsp:logic>
                boolean debug=true;
                String[] names=parameters.getNames();
                if (debug) try {
                        for (int i=0; i &lt; names.length; i++)
                        {
                                <param>
                                <xsp:attribute 
name="name"><xsp:expr>names[i]</xsp:expr></xsp:attribute>
				<xsp:attribute 
name="value"><xsp:expr>parameters.getParameter(names[i])</xsp:expr></xsp:attribute>
                                </param>
                        }
                }
                catch (Exception e) {}
</xsp:logic>

<!--
  Une adaptation de document.xsp dans sdxtest (on pourrait aussi utiliser
  sdx:includeDocument). On effectue une recherche sur la base indiquée 
par la variable
  String base, définie plus haut, avec le contenu d'un paramètre sitemap.
  Pareil pour le docid. Avec une application sdxtest déjà chargée, cela
  fonctionne chez moi.
-->
        <sdx:executeFieldQuery field="sdxdocid" valueString="docid" 
baseString="base"
        hpp="1" docs="true" hiliteParam="qid"/>

    </sdx:page>
</xsp:page>