David Verdin wrote:
<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 ?
La compatibilité ascendante est maintenue ! Ca a ses bon côtés, mais
aussi l'inconvénient que ça n'encourage pas les pratiques plus "modernes".
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.
C'est un des avantages de Cocoon: on peut faire plein de trucs sans
connaître Java, mais c'est aussi un des inconvénients, parce qu'on
arrive parfois à des constructions qui certes fonctionnent, mais sont
réellement difficile à comprendre quand on reprend un projet. Ah, et
bien sûr, ne pas oublier qu'une sitemap et une XSL sont des *programmes*
: à ce titre, il faut les commenter !!
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.
No problem !
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.
Pas besoin de doc : si tu sais manipuler les attributs de session sont
les mêmes pour tous les servlets d'un même contexte.
À 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 ?
Nous, on fait plutôt des applis intranet ou hébergées sur nos propres
machines, alors je ne saurais dire s'il y a des hébergeurs avec une
offre spécifique. Mais tu peux toujours louer un serveur dédié et y
installer Tomcat et Cocoon.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
---------------------------------------------------------------------
Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/
Pour vous desinscrire : mailto:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
