RE : RE : [sdx-developers] Getting started

[Martin Sevigny]

Bonjour,

> > Ah bon! Sous quel OS?
>
> Win 98... configuration Tomcat par défaut ; j'ai dû laisser
> passer qqe
> chose...

Pas nécessairement, je n'ai jamais testé là-dessus. C'est quoi Win98 ?
;-)

> > Personnellement, je mettrais ce flag dans un application.xconf.
>
> ... ce qui sous-entend que tu as pu instancier ton objet Application.

Je vois ce que tu veux dire. Mais si on a le paramètre comme attribut de
/sdx:application, alors seule deux situations peuvent empêcher de voir
le flag :

- document XML pas bien formé
- pas de /sdx:application

Pas trop mal...

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

Ca c'est autre chose. J'avoue que je ne sais pas quelles erreurs il peut
y avoir à l'initialisation du framework (sauf celles qui concernent les
applis). A explorer.

> 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]/s
dx:repository[3]").
> Avec, bien sûr, son corrolaire :
> confObject.getConfiguration().set("/sdx:application/sdx:databa
> se[1]/sdx:repository[3]",
> my_repository_object).
> Bref, pour ne rien vous cacher, les objets Properties me gonflent :-)

C'est JAXB (http://java.sun.com/xml/jaxb/), non? Ou l'équivalent (Castor
par exemple). Ce serait beaucoup de changements toutefois. Je n'en
ferais pas une priorité...

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

Justement, pour aller dans l'interface d'administration il faut montrer
patte blanche, non?

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

Sais pas. C'est pour ça que je ne suis pas allé plus loin dans mon
précédent message ;-)

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

Peut-être qu'une solution (simple) serait d'ajouter un
"getfieldsdefinition?app=...&db=..." dans l'API-URL...

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

Payé? En réfléchissant à leur structure? S'ils ont réfléchi à leur
structure de manière linéaire comme les champs SDX, je serais curieux de
voir leur structure ;-)

Pour moi c'est deux réflexions assez différentes...

> Je pense essentiellement à la posibilité d'indexer
> dynamiquement une DTD
> (ou mieux, un schéma qui, lui, permet des contraintes de type) comme
> Docbook.

Cocoon/Lucene le fait ;-) Il indexe tout! D'autres outils aussi (celui
de Kimber dont je faisais référence récemment).

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

Normalement oui. Un problème?

Martin Sévigny