Re: RE : [sdx-users] Applications de test

[Pierrick Brihaye]

Re,

Emmanuel Bégué a écrit:

> (sur http://www.nongnu.org/sdx/docs/html/doc-sdx2/fr/migration/ vous
> n'avez pas l'air de dire que les différences entre sdx1 et 2 soient
> tellement grandes?).

En fait, c'est essentiellement le déploiement qui est différent. En 
arrivant directement sur SDX2, vous avez évité les affres d'un 
déploiement pas toujours facile :-) Il n'était d'ailleurs généralement 
pas imputable à SDX lui-même, mais au couches logicielles de plus bas 
niveau.

Par rapport à SDX 1, SDX 2 offre les avantages suivants :

Une application peut être multibase. Elle était monobase auparavant. 
Pour faire court, mettez dans la même base tout ce qui donnera une 
indexation identique. Ca peut poser de gros dilemnes :-)

Ensuite, une base peut disposer de plusieurs entrepôts. Auparavant, on 
n'en avait qu'un seul, de type JDBC, ce qui obligeait à :

1) utiliser un SGDB
2) *dupliquer* les documents d'origine (qui étaient purement et 
simplement copiés dans le SGDB)

Désormais, vous avez en plus :

1) un FSRepository qui stocke les fichiers dans le système de fichiers 
de SDX (mais qui, fondamentalement, impose toujours la duplication dont 
on vient de parler). Plus besoin de SGDB !
2) un URLRepository qui permet de *faire référence* à des URL. On n'est 
donc plus obligé de dupliquer. Ouf ! Attention cependant, l'indexation 
faire à un instant t peut ne plus correspondre à l'état t + n du 
document référencé.

Je pense que l'on pourra disposer en 2003 d'autres types de repositories 
(j'en reparlerai).

Sinon, pour les *principes*, c'est strictement la même chose :

La logique est regroupée dans une ou plusieurs xsp. Cette logique 
utilise essentiellement les "actions" SDX dont la bibliothèque ne 
demande qu'à s'étendre. Pour les logiques particulières, on a la 
possibilité d'utiliser les <xsp:logic>...

Les documents sont indexés de la même façon que sous SDX 1 : il faut 
qu'après passage dans la XSL d'indexation, ils aient la forme :
<sdx:document id="xxx">
  <sdx:field code="aaa">bla</sdx:field>
  <sdx:field code="bbb">blabla</sdx:field>
  ...
</sdx:document>

Vos XSL doivent savoir gérer les xsp traitées par SDX. Pour avoir une 
idée du travail qui vous attend et, d'une façon générale, du 
fonctionnement intrinsèque de sDX, voyez les xsp de sdxworld après leur 
traitement pas SDX en utilisant des url *.xsp2sdx.

En gros, la dynamique est la suivante :

- la xsp spécifie les actions à effectuer (login, chargement, recherche...)
- SDX, via sa logicsheet exécute les actions demandées (ou renvoie une 
erreur) et renvoie une représentation XML de ce résultat (y compris des 
erreurs).
- vos XSL transforment cette représentation XML en représentation le 
plus souvent HTML.

Je passe sur tout l'intérêt pratique qu'a Cocoon 2. On peut déboguer une 
appli sans pratiquement redémarrer le moteur de servlets (il reste 
quelques petits problèmes à résoudre dans ce domaine).

Je passe aussi sur le fait que la configuration de SDX2, en dépit des 
apparences, est beaucoup plus facile une fois qu'on a compris le rôle de 
chaque fichier de configuration.

Voilà, c'était un essai de contribution au document "Bien démarrer avec 
SDX" :-)

A bientôt,

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden