[sdx-developers] schema de application.xconf (ex "db_info.xml")

[Frédéric Glorieux]

Quelques réflexions pour le schema de "application.xconf" (ex db_info.xml)
Rien d'urgent mais envoyé pour que cela s'archive

    Ce fichier de configuration est surtout utilisé par le jar SDX, il
pourrait cependant apporter quelques commodités à l'utilisateur. Je pense en
particulier à des informations textuelles. Je viens d'en ressentir l'utilité
pour une application SDX1 avec une dizaine de champs. Renonçant à tester
tous les cas de listes de termes possibles et à mettre à jour l'xsl à chaque
révision dans l'indexation, j'ai gagné en clarté en pointant directement sur
les noms de champ (que les experts me pardonnent si je n'ai fait qu'inventer
l'eau chaude). Rendu là, on peut apprécier avoir quelques descriptions
(enfermées dans un genre <sdx:description/> autorisant HTML ou autres à
l'intérieur), afin par exemple de fournir une aide à jour pour des champs de
recherche avancée. Cela risque de devenir très utile avec le multibase et le
multilinguisme.
    C'est une question de design discutable, mais des feuilles de
transformation pourraient s'adosser directement sur cette source pour : une
présentation standard de l'application, une recherche avancée générique, un
squelette de mise en forme des champs brefs, un pré-fichier d'indexation, un
avant-formulaire d'édition  (si des paths sont précisé pour des noms de
champs) ... d'autres idées peuvent venir. J'y vois deux avantages: augmenter
pour le profane la configurabilité d'une application "en 3 clics", faciliter
l'import d'une nouvelle base ou de bases distantes. Cela peut encourager à
enrichir ce schéma, en tous cas il faudrait éviter qu le code java en ferme
trop le développement.

----- Original Message -----
From: "Pierrick Brihaye" <address@hidden>
To: "sdx-developpers" <address@hidden>
Sent: Thursday, May 30, 2002 9:46 AM
Subject: [sdx-developers] Le code


Salut,

J'ai pas mal regardé le code puis la sortie de SDX 2. J'y ai corrigé
quelques typos, reformaté la doc et mis quelques TODO. Je vous concède
que ce n'est pas très productif, mais bon, c'est un prise de contact...

J'ai découvert la puissance des classes Framework/Application. Très
impressionnant même si tout ça est encore du chinois pour moi.

Premières questions :

- La plupart des classes ont désormais *deux* loggers ?
- Je comprends mieux le FSRepository. A la lecture de la doc (pas très
claire encore...), je me demande si cette classe ne devrait pas plutôt
s'appeller OwnSDXRepository, SDXInternalRepository ou quelque chose
comme ça, bref un truc qui indique qu'on n'a pas le droit de mettre les
pattes dedans :-)
- On a des méthodes isDef, getDef... à renommer avec les plus
traditionnels isDefault, getDefault ?
- utils/database : là encore, il me semble que le nom porte à confusion
(avec Base et, intellectuellement, avec Application qui pour la plupart
des utilisateurs doit encore être synonyme de "Base"). Là encore, si
j'ai bien compris, c'est un truc interne à SDX pour qu'il sotcke ce dont
il a besoin. Un nom comme systemDatabase/systemData (en lie et place des
"Entity") pourrait peut-être convenir... je commence d'ailleurs à
réaliser la puissance de ce package et j'en reparlerai probablement ;-)
- pas de possibilité pour l'instant de *recréer* les index ? Sous
sdx_v1, c'est là où j'ai rencontré le plus de problèmes et c'est une
opération que j'ai dû renouveller plusieurs fois. Mais bon, c'est
peut-être contournable (sur un URLRepository) en faisant un deleteAll et
en réinjectant les documents.

Voilà, voilà. Je pense que j'aurai une meilleure connaissance dans les
prochains jours et j'enverrai des propositions à court et à moyen terme.
En tout cas, bravo !

PS : heureux que le problème du lock ait été résolu.

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



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