Re: RE : RE : [sdx-developers] Getting started

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

> Pas nécessairement, je n'ai jamais testé là-dessus.

Mmmh. Bizarre : Tomcat est normalement indépendant de l'OS :-) Quand 
j'aurai trouvé, je posterai sur [sdx-users] ; ça peut servir à d'autres.

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

C'est précisément ça que je voudrais : un débutant peut *aussi* se 
planter dans la définition des applis :-) L'exemple que j'ai suggéré (2 
applis avec la même id, ce qui peut arriver en cas de copier-coller trop 
rapide) tombe précisément dans ce cas de figure... d'où ma suggestion de 
placer ça au niveau du Framework, c.a.d. dans cocoon.xconf.

> C'est JAXB (http://java.sun.com/xml/jaxb/), non? 

Ca y ressemble :-) Mais tout ça est encore très théorique pour moi et 
j'ai hâte de le voir fonctionner dans un contexte de configuration "de 
l'extérieur" similaire à la logique Avalon.

> Ce serait beaucoup de changements toutefois. Je n'en
> ferais pas une priorité...

J'en suis bien conscient. D'un autre coté, je me demande si ce genre de 
syntaxe (et son implémentation) ne pourrait pas faire gagner du temps à 
terme : un bon X-Path et des accesseurs simples, c'est tout de même plus 
évident que des Properties pour lesquelles il faut sans arrêt jongler 
avec la clé et qui, surtout, sont assez difficiles à hierarchiser. 
M'enfin, c'est une piste de recherche ;-)

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

Certes, mais, une fois de plus, ça sous-entend qu'on a été reconnu et 
donc que la sdx:userDocumentBase a été convenablement instanciée. Un 
servlet à la Cocoon.xsp, contrôlé au niveau du cocoon.xconf, serait plus 
simple à utiliser... mais il faut coder :-)

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

Ca tient la route... Mais bon, la solution XSP n'est pas mal non plus : 
a priori, le processeur XSLT appartient *bien* au processus "sdx". Peu 
importe : ce concept est complètement étranger à Win98 ;-))

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

L'exemple était un rien provocateur :-) En fait, voilà ce que je veux 
faire :

J'aurai des éléments dans un namespace donné, disons "inv". Dès lors que 
j'ai <inv:deno>, <inv:loca>, <inv:date> dans mon document, document qui 
sera *sémantiquement* validé à la production, je voudrais avoir une 
création *dynamique* de "champs" : deno, loca, date...

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

Ben, j'ai repris l'application.xconf de sdxworld qui est assez 
restrictive. Chez moi, sous localhost, ça passe. Pour autant que j'aie 
bien vu, ça ne devrait pas !? Je verrai ça plus en détail ce soir...

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