Re: RE : RE : RE : [sdx-developers] Directory URL

[Pierrick Brihaye]

Re,

Je me réponds à moi même au fur et à mesure que "j'avance" :-)

Pierrick Brihaye a écrit:

> ... ce qui a l'air d'être au point (sauf que je n'ai pas encore réussi à 
> récupérer ce document attaché via l'API-URL :-).

C'est en tout cas comme ça qu'on faisait dans SDX 1 parce que SDX 1 
stockait les documents (vs. le comportement actuel qui, via les 
repository URL, permet un simple référencement).

Donc, dans le code actuel, il semble que je doive utiliser :

http://localhost:8080/sdx/sdx/api-url/get?app=fr.gouv.culture.sdx.sribzh&id=IVR53_012916736NUCA_V.jpg

Manque de pot, dans la tabglib, <xsl:template 
match="sdx:includeDocument">, on postule que le document est parsable :

sdx_document=new XMLDocument(sdx_id);
...
sdx_base.getDocument((ParsableDocument)sdx_document,new 
IncludeXMLConsumer(sdx_consumer),sdx_bool);

Noter l'amusant : /* don't know type */ J'ajoute, "assumed parsable".

Moi, je veux bien : c'est très pratique pour envoyer un document 
parsable dans un pipeline (celui de surlignement par exemple ;-).

Par contre, ça appelle :
public void getDocument(ParsableDocument doc, XMLConsumer consumer, 
boolean docTypeKnown)

Alors que dans mon cas j'aurais voulu appeler :
public InputStream getDocument(Document doc)

Question : ne peut-on d'abord faire un test, par exemple sur le type 
MIME, pour savoir quelle méthode appeler ?

Pour info : la stacktrace
java.io.UTFDataFormatException: invalid byte 1 of 1-byte UTF-8 sequence 
(0xff) at 
fr.gouv.culture.sdx.exception.SDXException.log(SDXException.java:115) at 
fr.gouv.culture.sdx.exception.SDXException.<init>(SDXException.java:103) 
at fr.gouv.culture.sdx.document.XMLDocument.parse(XMLDocument.java:208) 
at 
fr.gouv.culture.sdx.repository.URLRepository.toSAX(URLRepository.java:393) 
at 
fr.gouv.culture.sdx.documentbase.LuceneDocumentBase.getDocument(LuceneDocumentBase.java:1566) 
at 
fr.gouv.culture.sdx.documentbase.LuceneDocumentBase.getDocument(LuceneDocumentBase.java:1611) 


Vous me direz que quand on utilise des repository URL, l'appel à la 
taglib n'est pas ce qu'on fait de mieux car ça donne de la charge 
inutile à Cocoon. Vous aurez raison :-)

Ca me pose néanmoins 2 problèmes :

On n'a aucun mécanisme qui nous retourne l'URL du document actuel, ce 
qui pourrait nous permettre de construire une "base" (car, évidemment, 
mes documents attachés travaillent en relatif).

Depuis SDX 1, j'aurais bien aimé un élément du genre :

<sdx:includedDocument id="xxx" mimetype="aaa" url="bbb"/>

Par ailleurs, j'ai monté un repository URL, mais j'aurais pu en monter 
un d'un autre type qui lui, n'aurait pas eu d'autre moyen que de passer 
par l'API-URL. C'est pour ça que je préfère unifier tout ça en utilisant 
cette API.

Bien sûr, si vous avez un "truc" assez générique, je suis preneur :-)

Note : ça rejoint une discussion en cours sur [pleade-users]. Je vais 
essayer d'en reparler...

PS : je suis assez surpris de l'attribut LuceneQuery sur une fieldQuery. 
Si j'ai field="aField" et value="aValue", j'ai LuceneQuery="aValue" 
(j'attendais "aField:aValue"). Je me suis dit que j'étais dans le cas 
particulier du champ par défaut. Il semble malheureusement que ce ne 
soit pas le cas.

A+

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