sdx-developers
[Top][All Lists]
Advanced

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

Re: [sdx-developers] Une base de documents sans entrepot?


From: Pierrick Brihaye
Subject: Re: [sdx-developers] Une base de documents sans entrepot?
Date: Fri, 16 Jul 2004 09:22:06 +0200
User-agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.6) Gecko/20040113

Salut,

Martin Sevigny a écrit :

Sinon, dans le cas "normal", le repo est bien dépendant de la DocumentBase, non ?

Ah, je vois ce que tu veux dire dire. Pour moi ce n'est pas une dépendance, c'est un "scope", il n'est pas visible pour les autres...

Joli :-) Bon, ben... dans ce cas, je préférerais le scope inverse :-)

Si je te suis bien, dans le cas d'un "non-repository", il faudra donc aller chercher le document... autrement ?!

Non, pas du tout, j'ai peut-être oublié de dire un point important, mais si on n'a pas d'entrepôt, alors il ne faut pas demander à SDX d'aller chercher le document!

... et Candide de poser 2 questions :

1) A quoi ça sert alors ?
2) Pour moi, il y avait là une opportunité d'aller chercher soi-même son document (i.e. hors du contrôle de SDX) en implémentant une interface ad hoc... qui existe déjà au demeurant. Il va de soi que dans le cadre d'une belle intégration Cocoon, ça passerait par des Readers.

Tout le problème, comme dit plus haut, c'est de savoir *comment* implémenter GetDocument. ici encore, SDX propose des "convenience methods" (les différentes GetDocument) mais dans quelle mesure le développeur d'appli ne pourrait-il pas lui aussi greffer les siennes ?

Ouais, mais dans ce cas pourquoi n'implémente-t-il pas un Repository?

Si le document est unitaire, c'est effectivement la solution : SDX propose des convenience methods éprouvées (j'aime bien l'URLRepository).

Je me plaçais dans un cas de figure plus particulier où un "document" (i.e. un truc qu'on veut indexer et donc rechercher) serait un montage plus complexe : enregistrement de BD, images dont on extraierait les vecteurs "significatifs", document dont l'URL varie en temps réel... Bref, un truc qui introduit toute la variabilité possible dans la notion même de document.

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden
+33 (0)2 99 29 67 78




reply via email to

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