sdx-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sdx-developers] RE : Utilisation des tables associees


From: Martin Sévigny
Subject: [sdx-developers] RE : Utilisation des tables associees
Date: Tue, 18 Jun 2002 10:47:31 +0200

Salut,

> > Personnellement, je n'utiliserais pas les tables SDX pour 
> ton cas, car
> > je pense que tu vas en trouver les limites rapidement. 
> 
> 
> Euh, en quoi seraient-elles différentes de limites SQL standard ?

Essentiellement parce que c'est une seule table. Et tu es limité par une
requête SELECT avec un WHERE et un ORDER BY, mais pas de GROUP BY.

> OK. Il faudra que tu me briefes là-dessus.

Dans le sdx.xconf, tu peux déjà spécifier un pipeline par défaut pour
l'indexation. Pour l'instant, c'est le seul supporté. Ce pipeline (un
concept SDX ici, pas Cocoon) contient des étapes qui sont (pour
l'instant) soit des XSLT soit des instances de l'interface
fr.gouv.culture.sdx.pipeline.Transformation. Ce dernier cas est,
essentiellement, un filtre SAX paramétrable.

Donc tu peux avoir un pipeline tel que :

<sdx:pipeline>
  <sdx:transformation type="xslt" url="indexation.xsl"/>
  <sdx:transformation class="GISInterceptor"/>
</sdx:pipeline>

(la deuxième transformation n'est pas supportée pour l'instant, mais
c'est un oubli)

Dans ce cas, un objet de la classe GISInterceptor serait instancié, et
il recevrait des événements startElement, endElement pour tout ce que
renvoie la XSLT, donc en général des <sdx:document> et <sdx:field>.
Cette classe fait ce qu'elle veut, mais elle doit envoyer des
informations à son "consommateur" qui est ici la "fin" du pipeline
d'indexation. Dans un tel scénario, elle passerait directement les
événements qu'elle reçoit (ce qui est le comportement par défaut de la
classe AbstractTransformation, donc héritage...).

C'est bien, mais en fait c'est statique, donc ça peut être limité pour
ce que tu veux faire.

Par contre, éventuellement (bientôt), tu pourras définir un pipeline _au
moment de l'indexation_, dans une XSP, avec une construction du genre :

<sdx:uploadDocuments ...>
  <sdx:pipeline>
    <sdx:transformation type="xslt" url="indexation.xsl"/>
    <sdx:transformation class="GISInterceptor">
      <sdx:parameter name="connectioName" valueVar="conn"/>
    <sdx:transformation>
  </sdx:pipeline>
</sdx:uploadDocuments>

(le XML des paramètres est à définir, ici disons que la valeur du
paramètre sera la variable conn définie préalablement)

Donc il sera possible d'avoir un pipeline totalement dynamique, et qui
pourra agir comme il l'entend, par exemple pour insérer des données dans
un GIS.

C'est plus clair?

> Tout ça me va. Ce que j'ai du mal à saisir est comment tout cela se 
> configure ? Avoir une classe spécifique pour gérer ça ne me 
> dérange pas 
> (et, si elle fait son boulot), on pourra toujours la mettre dans la 
> sdx-sandbox ;-) mais j'aimerais bien que tout cela apparaisse 
> clairement 
> dans les xconf. Question de padagogie évidemment...

Oui, bien sûr. Ca s'en vient...

A bientôt,

Martin Sévigny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]