RE : [sdx-developers] Getting started

[Martin Sevigny]

Bonjour,

> forcément explicite. Certes, tout cela apparait dans les 
> logs, mais, comme Tomcat n'écrit ces logs qu'en fin de 
> session, 

Ah bon! Sous quel OS? Sous Windows 2000/XP, ça s'écrit au fur et à
mesure... Mais ça ne change rien au problème...

> - à l'aide d'un flag (proceedonbadconfiguration ?) dans 
> cocoon.xconf, on pourrait choisir de lancer ou d'ignorer les 
> exceptions de configuration.

Personnellement, je mettrais ce flag dans un application.xconf. Ayant à
gérer des serveurs avec plusieurs applis pas toutes sous ma
responsabilités, j'essaie d'en mettre le moins possible dans
cocoon.xconf ou sdx.xconf... Mais (voir plus loin), je signale aussi que
je ne mettrais pas ce flag...

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

Je ne crois pas. Mais ça prendrait une méthode toSAX() à la classe
Application et toutes les classes (DocumentBase, etc.) qu'elle
"contient". On pourrait ainsi obtenir une représentation XML.

Celle-ci serait "canonique", c'est-à-dire que les valeurs par défauts
seraient présentes. Donc pas nécessairement la même chose que le XML
original... C'est plus simple ainsi...

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

Je prendrais cette dernière option. A ajouter dans l'interface
d'administration. En fait, inutile de mettre un paramètre quelconque, ou
même un flag : ça devrait toujours être disponible, non?

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

Ton commentaire sur les null/erreurs de paramètres mérite réflexion...
J'y reviendrai.

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

Je suis d'accord. Devrait être XML.

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

Non, tu n'as rien laissé passé, il faudrait que l'on puisse charger
également des URLs. Ce n'est pas vraiment plus compliqué...

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

Il remplaçait un autre document avec le même id? Par défaut, seules les
statistiques et les erreurs sortent dans les log d'upload. Pour avoir
les sdx:uploadDocument, il faut mettre quelque chose comme show="all"
(je ne me rappelle plus par cœur). Maintenant, il faudrait appliquer la
même logique au sdx:deletion...

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

<select name="..">
 <xsl:for-each
select="document('../conf/application.xconf')/sdx:application/sdx:docume
ntBases/sdx:address@hidden'...']/sdx:fieldList/sdx:field">

  <option value="address@hidden"><xsl:value-of select="name"/></option>

 </xsl:for-each>
</select>

[non testé...]

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

C'est-à-dire indexer avec <sdx:field name="" type="field..."
xml:lang="fr"...>blah blah</sdx:field>? Ce serait techniquement
possible, mais ça pose quelques problèmes :

- il faut lire l'index (et même là je ne suis pas certain si c'est
possible) pour savoir de quel type est un champ
- s'il n'y a pas de document ou si aucun document n'utilise un champ
(pour le moment) on ne connaît pas la nature du champ...

Mais la vraie raison c'est que je considère que le développement d'une
application passe par une phase de réflexion. Mais c'est mon dada à moi,
je suis prêt à faire des concessions ;-)

> - le fichier sur la "planification de l'espace disque" n'est 
> pas dans le CVS. Dommage, j'y ai repéré quelques typoes...

Oups! Mon oubli. Corrigé.

Martin Sévigny