Re: [sdx-developers] COP

[Pierrick Brihaye]

Bonjour,

Nicolas Maisonneuve a écrit:

> c'est ce que j'ai un peu regretté dans SDX...   on ne devrait voir que 
> des composants  cocoon (generateur, action, transformer)  ou avalon ..
> mais ils sont assez rare ..

Mmmh. On a tout ce même pas mal de composants Avalon, non ? Bon, c'est 
vrai, certains pourraient plus coller à certaines classes standard ; je 
pense en particulier au package fr.gouv.culture.sdx.document qui est 
dans l'esprit assez proche de org.apache.excalibur.source. Il aurait été 
aussi intéressant de pouvoir réutiliser l'approche de 
org.apache.avalon.excalibur.datasource pour les repositories, mais la 
méthode clé, getConnection() est typée... java.sql.Connection :-(

En ce qui concerne la faible utilisation de composants Cocoon, cela est 
lié à des raisons historiques. Sous Cocoon 1, le générateur XSP restait 
la voie royale. On a donc une taglib assez fournie qui, c'est vrai, 
aurait peut être intérêt à déporter une partie de son code dans des 
générateurs/transformers. Je reste néanmoins très attaché à cette taglib 
qui, IMHO, est plus facile à appréhender par des novices qu'une Sitemap 
de plusieurs Ko.

Un autre point important est que SDX est une appli Cocoon 2.x. Elle n'a 
donc pas été pensée en termes de blocks Cocoon 2.1. Il y aurait 
également quelque chose à faire de ce côté.

> et on perd ainsi tout la flexibilité de 
> cocoon ..

Commentaire personnel : avec ses fichiers de config dispersés ça et là, 
je ne sais pas si Cocoon est si flexible que ça :-) Enfin... les blocks 
pourraient considérablement arranger ça...

> Une minuscule contribution.. qui ne servira surement pas à grand chose 
> puisque SDX a son propre mécanisme.

Je reconnais néanmoins que c'est ce vers quoi il faut tendre. Pour des 
raisons historiques, on fait un mapping des champs sur une structure 
dédiée (FieldsDefinition), ce qui n'est pas forcément nécessaire. Il 
"suffirait" qu'une (Lucene)DocumentBase transmette le flux à un 
(Lucene)IndexationTransformer. Elle pourrait également lui transmettre 
ses "system fields".

Petite note sur le transformer : on optimise et on ferme le writer sur 
le dernier élément <index/> (dernier élément du document d'indexation en 
fait). Qu'en est-il de la performance ?

A bientôt,

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