Re: [sdx-developers] COP

[Nicolas Maisonneuve]

>Mmmh. On a tout ce même pas mal de composants Avalon, non ? Bon
y'a des classes qui utilisent des interfaces d'avalon.. mais je n'ai pas vu
dans vos source , un lookup(moncomposant.role);
ni des declarations de composant dans cocoon.xconf .. donc ils ne sont pas
mis dans le conteneur
et ne sont pas traités en tant que composant mais seulement en tant que
classes ordinaires .. (evidemment on perd tout l'interet  car on a plus la
gestion du lifecycle  du composant fait par le conteneur, seul avantage d'un
composant par rapport à une classe ordinaire)

dans cocoon.xconf , y'a juste un composant de déclaré..
    <oai role="fr.gouv.culture.oai.OAIComponent"
class="fr.gouv.culture.oai.OAIComponentImpl" logger="oai"/>
 (j'ai l'impression que le package OAI a été fait plus 'esprit composant
...)

bon j'avoue..j'ai survolé rapide.. donc j'ai pas du tout voir..

>org.apache.avalon.excalibur.datasource pour les repositories, mais la
>méthode clé, getConnection() est typée... java.sql.Connection :-(
ha.. j'suis content de cette remarque .. car je voulais aussi utiliser cette
interface  pour un composant utilisant Xindice (d'ailleurs à quand un
repositories xmldatabase dans SDX..)
et j'ai eu la meme surprise.. dommage que cela soit pas plus generale comme
interface..
d'ailleurs je vais poster un mail sur ce problème sur la mailing list Avalon

>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...
y'a pas des dizaines de fichiers de config ..
a part cocoon.xconf, lieu de toute la configuration des composants
et les sitemap..(en ai je oublié ?)

>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 ?

pour mon transformer... j'avoue que je n'ai pas spécialement testé les
performances..
par contre  je ne comprend ou est le problème dans l'optimisation et la
fermeture du writer,  y' a til une mauvaise facon de faire ?

En ce moment, je suis en train d'avaloniser mon projet en m'inspirant de
quelques fragments de code de SDX :

j'ai  créé ainsi l'analyserManager (inspiré de SDX mais plus simple)
me permettant  avec getAnalyzer(id) de me donne le bon analyzer
configurable de la facon suivant :

<analyzer_manager logger="ecr.analyzer_manager">
 <!-- configfile is optional. used for the Analyzer class with the Avalon
Configurable interface -->
 <analyzer id="fr"
class="org.paris5.component.index.analysis.analyzer.Analyzer_fr"
configfile="/resources/fr.xml"/>
<analyzer id="default" class="org.apache.lucene.analysis.standardAnalyzer"
/>
<analyzer id="education"
class="org.paris5.component.index.analysis.analyzer.Analyzer_fr"
configfile="/resources/education.xml"/>
 <analyzer id="en"
class="org.paris5.component.index.analysis.analyzer.Analyzer_en"
configfile="/resources/en.xml"/>
</analyzer_manager>

un indexbaseManager (un documentBase pour SDX, sans les repositories,
histoire de séparer un maximum )  en phase de dev... (le binding sera enlevé
et mis dans un composant dédié à la transformation d'un XML en
lucene.document.. ) ce composant n'est vraiment pas achevé d'un point de vue
concepts car je n'ai pas encore touché au problème(s) de la recherche)

<indexbase_manager>
<indexbase id="componentbase" directory="d:\\index" defaultIDAnalyzer="fr">
 <fieldList>
  <!-- a field with id ="INDEXID" type="keyword" is already implemented and
must be referenced in bind section -->
  <field id = "title" type="keyword"/>
  <field id = "description" type="text"/>
  <field id = "date" type="date" dateformat="MM/dd/yyyy"/>
 </fieldList>

 <binding>

  <documentxml URI="http://www.ecr.org/description/1.0";>
   <bind xpath="/:description/:ID" idref="INDEXID"/>
   <bind xpath="/:description/:title" idref="title"/>
   <bind xpath="/:description/:date" idref="date"/>
   <bind xpath="/:description/:description" idref="description"/>
  </documentxml>

  <documentxml URI="http://www.ecr.org/description/2.0";>
   <bind xpath="/:description/:ID" idref="INDEXID"/>
   <bind xpath="/:description/:title" idref="title"/>
   <bind xpath="/:description/:general/:date" idref="date"/>
   <bind xpath="/:description/:general/:description" idref="description"/>
  </documentxml>

 </binding>
</indexbase>

<indexbase id="componentbase2" directory="d:\\index2"
defaultIDAnalyzer="en">
 <fieldList>
  <field id = "title" type="keyword"/>
  <field id = "description" type="text"/>
  <field id = "date" type="date" dateformat="MM/dd/yyyy"/>
 </fieldList>
</indexbase>

</indexbase_manager>

je pense aussi faire un writerManager qui gère justement le problème de la
demande de plusieurs instances de writer pour la meme base index
et aussi plusieurs composants  pour  le role de XMLtoLucene

enfin bon.. si y'a des composants qui vous interesse..  mon code est open
source :)

----- Original Message -----
From: "Pierrick Brihaye" <address@hidden>
To: <address@hidden>
Sent: Monday, September 01, 2003 9:54 AM
Subject: Re: [sdx-developers] COP


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



_______________________________________________
sdx-developers mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/sdx-developers