[sdx-developers] Getting started

[Pierrick Brihaye]

Salut et bonne année à tous !

J'ai repris le titre d'un thread de [sdx-users] parce que, étant en train de
monter une appli, j'ai eu quelques problèmes pratiques qui, pour un
débutant, ne sont peut-être pas évidents à résoudre...

Ca concerne avant tout la configuration des applis (fichiers
application.xconf). Le design a choisi délibérement de ne pas rendre
bloquantes les exceptions de configuration dans les objets de "rang
inférieur" : dbs et repositories. Ce choix est complètement défendable car,
pour tout un tas de raisons, on ne voudra/pourra peut-être pas mettre à
disposition ces objets.

Le problème, c'est que lorsqu'on essaie d'y accéder, ça coince et que ça
provoque des exceptions qui sont difficiles à tracer dans la mesure où un
débutant sera persuadé qu'il a bien tout configuré, surtout que le message
de log n'est pas forcément explicite. Certes, tout cela apparait dans les
logs, mais, comme Tomcat n'écrit ces logs qu'en fin de session, on risque de
bidouiller longtemps avant de trouver l'origine exacte du problème... ce qui
nous renvoie à l'époque de SDX 1 alors que SDX 2 offre, au moins sur le
papier, la possibilité de travailler sans arrêter/relancer le moteur de
servlets.

Je propose donc les solutions suivantes, du plus simple au plus compliqué :
- à l'aide d'un flag (proceedonbadconfiguration ?) dans cocoon.xconf, on
pourrait choisir de lancer ou d'ignorer les exceptions de configuration.
- on pourrait avoir un tag <sdx:showConfiguration> qui générerait une
aborescence similaire à application.xconf (grâce à des méthodes
configurationToSAX ?). Un diff entre les 2 arbres permettrait de voir ce qui
n'a pas été pris en compte... Mais peut-être que les déveoppeurs
Cocoon/Avalon se sont penchés sur le problème ?
- on pourrait avoir un servlet (ou un paramètre de request pour le servlet
sdx) qui, à l'instar de ce qui se fait pour Cocoon, affiche la configuration
actuelle. Ici encore un flag (allowconfigurationdisplay ?) pourrait être
utile dans cocoon.xconf... ou un test sur le super-utilisateur ou un admin
d'application.

Ensuite, j'ai quelques problèmes avec la taglib : j'ai relativement bien
compris comment les objets étaient instanciés (hard-coding, paramètres de
request...) mais, à la transmission dans la logique, je trouve qu'il a a
quelques faiblesses. Supposons qu'on ait un paramètre null. De deux choses
l'une :

- on le transmet à l'API qui ne devrait pas manquer de provoquer une
exception "propre"
- on crée une exception depuis la taglib

En fait, il semble que l'on soit sur une "voie moyenne" que je ne trouve pas
très satisfaisante. Elle est essentiellement dû à des structures comme ça :
if (sdx_object1 != null) {

}
else if (sdx_object2 != null) {

}

... sans else final.

On peut aussi s'assurer, si le paramètre est effectivement transmis, qu'il
permet la construction d'un objet *valide* (un File égal à null n'est pas
selon moi un paramètres valide).

Certes, on peut là encore prendre le parti de ne pas lever d'exception si
une "action" SDX n'a pas reçu de paramètres *valides* pour garantir son
exécution correcte, mais je pense que dans ce cas, la xsp devrait retourner
un tag du genre <sdx:skippedAction name="uploadDocuments" reason="Too few
parameters : X, Y or Z sere expected"/> (ici, le schéma pourrait encore
aider à la rédaction du message).

Voilà : le reste est plutôt du ressort de [sdx-users], mais pendant que j'y
suis...

Pour les uploads :

On a <sdx:uploadDocument> qui prend :
- une url
- un fichier (local)
- une chaîne "xml"
- un dom

Excellent ! Sauf que "url" est typée *par défaut* en "text/html", ce qui est
étonnant pour un système documentaire... XML. Je sais bien que c'est comme
ça que c'est utilisé dans sdxworld mais de là à en faire le cas général...

On a <sdx:uploadDocuments> qui prend :
- un dir  (local)
- un zip (local)

Comment faire pour choper des zip, ou surtout des dir, distants ? Le concept
n'est pas incompatbile avec celui d'URLs, non ? Or, c'est précisément cela
qui m'intéresse étant donné que je vais utiliser des URLRepositories....
Mais bon, j'ai peut-être laissé passer quelque chose...

Toujours sur l'upload : j'ai un peu de mal à me rendre compte de la
cinématique, essentiellement à cause du fait que j'ai plusieurs choses à
gérer en même temps. En uploadant *un* fichier, je me suis retrouvé avec un
"log d'upload" (très astucieux) qui me donnait *un* élément <sdx:deletion>
mais pas d'élément <sdx:uploadDocument> correspondant. Bizarre, non ?

Autre chose : Serait-il possible d'avoir des fonctions utilitaires du genre
<sdx:showFieldList> qui me permettraient, par exemple, d'alimenter une combo
pour l'interrogation ? En l'état actuel des choses, je suis obligé de
hard-coder 2 fois ma liste de champs. Et j'en ai 158 ! Ca peut se fait
entièrement dans la taglib ou, mieux, en créant une méthode fieldListToSAX
dans LuceneDocumentBase car, IMHO, ce concept est (encore ;-) étroitement
lié à Lucene. On peut extrapoler à d'autres fonctions : utilisateurs,
groupes, statistiques...

Point connexe au précédent : j'ai suivi les récents développements de Lucene
qui offre maintenant un peu plus de possibilités d'accès aux métadonnées, ce
qui n'est pas du luxe. Dans ses conditions, est-il encore pertinent
d'imposer un hard-coding de la field list ? On pourrait peut-être faire
confiance à la transformation d'indexation pour la générer dynamiquement ?

Pour terminer sur ces premières impressions :

- la barre de menus de sdxworld, grise avec des insets quasiment nuls, ne se
distingue pas franchement de la barre de menus du navigateur si bien qu'au
premier accès, je me suis demandé où elle était :-)
- le fichier sur la "planification de l'espace disque" n'est pas dans le
CVS. Dommage, j'y ai repéré quelques typoes...

A bientôt,

p.b.