<snip/>
Argh, le fameux SourceWritingTransformer...
Ben c'est pas si mal pour stocker quelques informations qui n'ont pas
forcément besoin d'être organisées en base de données.
Pour le moment en tout cas.
Qu'est-ce qu'il a de mal, ce pauvre transformer ?
Il est dans la catégorie "composants de pipeline à effet de bord". On
y trouve aussi le SQLTransformer, ou aussi les XSP qui contiennent du
code applicatif. Du point de vue de la structucation
modèle/vue/contrôleur, cela signifie que la vue (le pipeline) modifie
l'état du système, ce qui n'est pas bon.
Dans Cocoon 2.0, l'entité représentant le contrôleur étaient les
actions. Cela nécessitait l'écriture d'une classe Java par action, ce
qui n'était pas forcément cohérent avec l'approche très dynamique de
Cocoon ni avec les compétences de ses utilisateurs, ce qui à conduit à
l'apparition de ces composants de pipeline à effet de bord, et des
constructions alambiquées pour faire de la logique métier avec. Et le
pire, c'est que j'ai largement contribué à l'écriture du
SourceWritingTransformer, à l'époque :-)
Faute avouée... ;-)
Cela dit, les actions existent toujours, tout comme les XSP.
sont ils amenés, ainsi que notre malheureux SourceWritingTransformer, à
disparaître dans un avenir proche (comme avec Cocoon 2.2) ou bien la
compatibilité descendante sera-t-elle maintenue ?
Cocoon 2.1 a apporté le flowscript, qui permet de définir très
simplement un contrôleur propre. Tous ces composants à effet de bord
peuvent être remplacés par du flowscript, qui peut éventuellement
s'appuyer sur des "pipelines de logique". Par ce terme, j'entends des
pipelines dont la finalité est de manipuler des données plutôt que de
construire une réponse pour l'utilisateur. On a pour ce faire une
classe "PipelineUtils" qui permet d'appeler un pipeline et récupérer
son résultat sous forme de stream, DOM ou SAX à des fins de traitement
complémentaire.
Certes mais, comme je le dis plus loin, l'abord de certaines fonctions
de flowscript n'est pas forcément immédiat.
Le SourceWritingTransformer peut donc avantageusement être remplacé
par qq chose du type:
var src = resolver.resolveURI("mon-fichier-destination");
pipelineUtil.processToStream("sauverRequete", src.outputStream);
cocoon.sendPage("session-enregistrée.html");
C'est plus court, et à mon avis beaucoup plus lisible.
Voui.
J'ai passé pas mal de temps dans les docs des fonctions de flowscript.
J'avoue qu'au bout d'un moment, pressé par les délais (je sais, c'est
mal de les laisser décider pour soi), j'ai préféré « bricoler » une
solution avec les transformers plutôt que de trouver la bonne solution
avec les flowscripts.
Mea culpa.
D'autant plus que l'on sent bien que ce genre de tâches d'arrière-plan
sont plus du ressort du flowscript que du sitemap.
Malheureusement, ma faible culture (mais j'y travaille !) du java m'a
fait m'embrouiller dans les sorties des diverses méthodes java, les
techniques d'importation et plus généralement les javadocs.
Cela dit, j'utilise en effet couramment les "pipelines de logique", mais
sans aller jusqu'au bout de la démarche. Je crois que j'ai compris : il
me manquait la classe "pipelineUtils".
Je vais continuer un petit moment avec ma solution batarde et essayer de
migrer progressivement vers quelques chose de plus solide.
<snip/>
Et comme une partie du système n'est pas dans cocoon, mais dans un
autre servlet, on utilise des cookies pour transférer les
informations de l'un à l'autre. La solution la plus simple m'a semblé
être d'enregistrer les cookies.
Si les 2 servlets sont dans le même contexte web (le même web.xml),
ils peuvent communiquer par les attributs de session.
On avait pensé à quelque chose comme ça, et puis bon, les cookies
marchent bien alors on s'est dit qu'on allait éviter d'aller trop loin
dans la doc de Tomcat.
À ce propos, ça n'a rien à voir, mais si ce projet devait donner
satisfaction, il faudra qu'on lui trouve un vrai hébergeur. Ça se
trouve, en France, un hébergeur Tomcat/Cocoon ?
David
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
