[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [sdx-developers] SDX 2.2 : suggestions d'ajouts mineurs
From: |
Rasik Pandey |
Subject: |
RE : [sdx-developers] SDX 2.2 : suggestions d'ajouts mineurs |
Date: |
Mon, 5 Jan 2004 10:30:18 +0100 |
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
- RE : [sdx-developers] SDX 2.2 : suggestions d'ajouts mineurs,
Rasik Pandey <=