[sdx-developers] Synthèse

[Pierrick Brihaye]

Bonsoir,

Petite synthèse des discussions sur [sdx-users] :

- comme je le pressentais, il semble que le nom des DB de sdxworld prête à
confusion. Je propose "projets" et "web" (ou "sites")

- comportement de l'upload : le code sur l'arbitrage a été viré. Pourquoi
pas (on était peu-être allés trop loin dans ce domaine) ? Mais, ne doit-on
pas avoir un paramètre si un utilisateur ne veut *pas* remplacer un document
existant ?

- possiblité d'un flag sur les uploads : deleteDocument qui détruirait le
document uploadé dans le répertoire source. Evidemment, ça n'a de sens que
sur un repository local. Pour un URLRepository, c'est carrément
contre-poductif :-)

- ôtez-moi d'un doute : dans la doc sur les paramètres, on énonce bien les
façons de les passer de la moindre priorité à la priorité la plus forte ?

- dans le upload.xsp de sdxworld, on a ça :

<sdx:pipeline>
  <sdx:parameter name="jour" valueString="jour"/>
  <sdx:transformation type="XSLT" src="../conf/index-html.xsl"
srcParam="index"/>
</sdx:pipeline>

Ce qui me chifonne, c'est l'URL relative "../conf/index-html.xsl". Mais dans
quel contexte est donc SDX pour qu'un truc comme ça puisse tourner ? Après
examen plus approfondi, j'ai trouvé ça dans XSLTTranformation.java :

* In addition to the parameters needed in the base configuration handled
* by the parent class, the "src" parameter is required and can be absolute
* or relative to the directory containing the application.xconf file
* or relative to the SDX installation.

Donc, si je suis dans le même répertoire que application.xconf, ce qui *est*
le cas, "index-html.xsl" devrait être bon, non ? J'ai essayé... sans succès
:-(

Sinon, d'autres choses :

- la doc anglaise est en avance sur le CVS des sources (il y a quelques
typoes ;-)

- on a des exceptions silencieuses dans le design de sdxworld : une mauvaise
URL dans l'attribut src de la transformation décrite ci-dessus renvoie une
page blanche. Un petit message aurait pu aider...

- interdit de rire pour celui-là : je demande à ce que cocoon.xconf (si on
travaille sur le framework) ou que application.xconf ait un élément de
définition de proxy pour permettre la résolution des URL.

A bientôt,

p.b.