RE : [sdx-developers] SDX 2.2 : suggestions d'ajouts mineurs

[Rasik Pandey]

Bonne année,

 >
 >Au moment de finaliser le code pour SDX 2.2, je vous fais 
 >part d'une liste de petits ajouts potentiels, qui ne 
 >remettent rien en cause et surtout n'ont aucun problème de 
 >compatibilité avec SDX 2.1.
 >
 >- indexation avec fragmentation
 >
 >Lorsqu'on indexe des documents fragmentés, on n'a une 
 >mauvaise information concernant le nombre de documents 
 >indexés (toujours 1), même si tous les sous-documents sont 
 >listés. La sortie de l'indexation pourrait être améliorée.

C'est fait.

 >- indexation avec documents attachés
 >
 >Il pourrait être intéressant d'avoir des informations sur les 
 >documents attachés lorsqu'on indexe, leur liste ou le nombre, 
 >selon les paramètres spécifiés.
 >

C'est fait. On les envoie quand on a 

if (contentHandler != null && params.getSendIndexationEvents() ==
IndexParameters.SEND_ALL_EVENTS)


 >- messages d'indexation
 >
 >Il pourrait être intéressant de supporter un élément 
 ><sdx:message> dans le document d'indexation (sortie d'un 
 >pipeline d'indexation) qui permettrait à SDX de logger ce 
 >message 

C'est fait.

Dans les logs on va essayer de faire qqch. comme

INFO    (2003-12-31) 18:40.33:687
[sdx.framework.sdxtest.sdxworld.{$docId}.sdx:message]
(/sdx22/sdxtest/upload.xsp) HttpProcessor[8080][1]/Utilities: texte du
message x x x x x x 


>mais aussi de le retourner dans les sdx:uploadDocument.

C'est fait.  Ca devrait être sorti dans le bon contexte des événements
SAX.


 >- lastModificationDate() dans DocumentBase pour faciliter la 
 >gestion des caches

C'est fait.

On a les deux dans DocumentBase:

Date lastModificationDate();
Date creationDate();


>- fieldlist réutilisables
 >
 >Dans application.xconf, permettre de définir des 
 ><sdx:fieldList id=""/> au niveau de l'application ou de la 
 >base de documents et y faire référence dans une (autre) base 
 >de documents : <sdx:fieldList ref=""/>, afin de permettre la 
 >constitution de multiples bases de documents partageant la 
 >même structure.
 >
 >Et encore mieux, si on a
 >
 ><sdx:fieldList ref="toto">
 >  <sdx:field name="tata" type="field"/>
 ></sdx:fieldList>

C'est fait. 

à tester avec 
<sdx:fieldList ref="REFID"/>
Et
<sdx:fieldList ref="toto">
 <sdx:field name="tata" type="field"/>
</sdx:fieldList>

 >Alors le champ tata est ajouté ou modifié s'il existait dans 
 >la liste "toto".
 >

Ça devrait marcher....


 >- mettre en évidence les mots dans les valeurs d'attributs
 >
 >Voir thread à ce sujet.

Est-ce qu'on pourrait faire qqch. comme:

<blah myAtt="x matchingWordFromSearch y" myAtt2="x
matchingWordFromSearch y" sdx:hilite="myAtt-startIdx:endIdx
myAtt2-3:24"/>


  >>Martin a écrit:
  >>- sdx:userIsAdminOrMember dans la taglib
  >>
  >>Utile dans certains cas pour permettre aux admin de faire des 
  >>opérations réservées à certains groupes.

 >Pierrick a écrit:
 >+1. A ce propos, ne serait-il pas intéressant de développer des
actions  >Cocoon pour ceux qui veulent gérer ça en Sitemap ? La taglib
pourrait 
 >efficacement en faire usage.
 
Je suis pour qqch en Sitemap, pourquoi pas qqch comme:
http://radio.weblogs.com/0103021/stories/2002/02/28/usingTheSunriseCompo
nents.html
http://cocoon.apache.org/2.0/developing/webapps/authentication.html

 
  >>Martin a écrit: 
  >>- permettre de définir des groupes et des utilisateurs dans 
  >>le .xconf (généraliser sdx:admin?)
  >>
  >>Ca peut être utile de préconfigurer une application avec des 
  >>groupes et des utilisateurs.
  >>
  >>Un truc comme ceci dans le xconf:
  >><sdx:usersAndGroups>
  >>  <sdx:user id="" password="" ...>
  >>    <sdx:group ref=""/>
  >>    <sdx:group ref=""/>
  >>  </sdx:user>
  >>  <sdx:group id="" name=""/>
  >>  <sdx:group id="" name=""/>
  >></sdx:usersAndGroups>
  >>
  >>Avec la même logique que pour l'admin : si on a un 
  >>utilisateur ou un groupe déjà défini pour le même id, on n'y 
  >>touche pas.

 >Pierrick à écrit:
 >+1. Et avoir la possibilité de définir un chemin vers un fichier
externe  >d'utilisateurs ? Même chose d'ailleurs pour le fichier de
config de base 
 >: ça éviterait, au démarrage d'une appli SDX "packagée" d'avoir à 
 >définir un SU.

ENCORE pourquoi pas qqch. comme:
http://radio.weblogs.com/0103021/stories/2002/02/28/usingTheSunriseCompo
nents.html
http://cocoon.apache.org/2.0/developing/webapps/authentication.html


  >>Martin a écrit:  
  >>- trier les sdx:terms (sur le nombre de documents par exemple)  
  >>Ca peut être utile dans certains cas.

 >Pierrick à écrit:
 >Vu la discussion à ce sujet... j'hésite encore sur la pertinence de ce

 >tri "partiel", mais bon... pourquoi pas ?
 
Je ne suivais pas trop. Qu'est-ce que vous voulez faire?

 >
 >- exploiter [Lucene]Document.setBoost() et 
 >[Lucene]Field.setBoost() au moment de l'indexation
 >
 >Pourrait se faire ainsi:
 >
 ><sdx:document boost="">
 >  <sdx:field boost="">
 >

C'est fait. À tester...


 >- intégrer ceci http://sourceforge.net/projects/normalizer/ ?  >  
 >C'est un normaliseur de mots, avec des règles de stemming 
 >pour le français, en GPL et avec déjà un analyseur compatible 
 >Lucene. Il y a aussi un soundex.

Vous le connaissez. La documentation est très légère.

La paramètre "inputfile" sert à quoi?

public NormalAnalyzer(File inputfile) 
    {
        m_processor = Processor.create(inputfile);
    }
 

Rasik