Re: RE : [sdx-developers] Getting started

[Pierrick Brihaye]

Salut,

Martin Sevigny a écrit:

> Ah bon! Sous quel OS?

Win 98... configuration Tomcat par défaut ; j'ai dû laisser passer qqe 
chose...

> Mais ça ne change rien au problème...

Exact :-)

> Personnellement, je mettrais ce flag dans un application.xconf.

... ce qui sous-entend que tu as pu instancier ton objet Application. 
J'ai fait quelques tests en balançant des valeurs illégales (vous pensez 
bien :-). Il faudra que j'aille plus loin en mettant 2 id d'applications 
identiques pour voir...

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

On est d'accord, mais, dans mon esprit, il s'agissait bien de tracer les 
exceptions qui pourraient survenir à l'initialisation du framework.

> > Mais peut-être que les déveoppeurs Cocoon/Avalon se 
> > sont penchés sur le problème ?
>
> Je ne crois pas.

C'est bien dommage :-( Petit apparté là-dessus : mon rève serait d'avoir 
un objet de configuration arborescent qui serait le pendant code du 
fichier xml. On pourrait y accéder via une syntaxe X-Path :
Object Repository my_repository = 
(Repository)confObject.get("/sdx:application/sdx:database[1]/sdx:repository[3]"). 
Avec, bien sûr, son corrolaire : 
confObject.getConfiguration().set("/sdx:application/sdx:database[1]/sdx:repository[3]", 
my_repository_object).
Bref, pour ne rien vous cacher, les objets Properties me gonflent :-)

> 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 est d'accord.

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

Mmmh. Je ne sais pas trop : il y a des infos qui ne sont peut-être pas à 
divulguer sans montrer patte blanche. M'enfin... c'est à voir.

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

On est d'accord. Que faire ? Instancier des URL (avec un protocole 
"file://" par défaut) en lieu et place des File ? Ou avoir des 
paramètres du style "urldir", "urlzip" ?

> Il remplaçait un autre document avec le même id? 

Je ne sais pas trop. Je vais me repencher sur le problème...

> Maintenant, il faudrait appliquer la même logique au sdx:deletion...

Probablement : j'ai l'impression qu'il y a une dyssymétrie à ce niveau. 
Je vais aussi regarder ça.

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

Je m'attendais à la réponse :-) Ca me pose quelques problèmes cependant :
1) Ca suppose qu'on ait une fieldList hard-codée (v. plus bas)
2) Ca suppose qu'on ait accès au répertoire. Or, selon moi, ce 
répertoire appartient à l'utilisateur "sdx"... et je ne sais si le 
processeur XSLT doit agir au nom de cet utilisateur...

> C'est-à-dire indexer avec <sdx:field name="" type="field..."
> xml:lang="fr"...>blah blah</sdx:field>?

Oui : ajouter l'analyseur... et le type (et le brief...). Ce qui semble 
répondre à ta question. Bien sûr, tout champ serait mis dans une 
HashTable ou similaire de façon à s'assurer que si il a été défini une 
fois avec tel typage, on ne puisse le redéfinir avec un autre. Il serait 
aussi pas mal que cette FieldList soit sérialisée (en XML, évidemment). 
Ca reviendrait à externaliser la partie <FieldList> de application.xconf .

> 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 ;-)

Les 2 logiques devraient être possibles. En fait, je pense 
essentiellement à des gens qui ont fait un gros effort de réflexion en 
amont, c.a.d. sur la structure des documents. Pourquoi leur imposer la 
rédaction fastidieuse d'une FieldList alors qu'ils ont déjà payé avant ? 
Je pense essentiellement à la posibilité d'indexer dynamiquement une DTD 
(ou mieux, un schéma qui, lui, permet des contraintes de type) comme 
Docbook.

Dernier point pour l'instant : est-ce que les restrictions/autorisations 
d'accès sont censées fonctionner ?

A bientôt,

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