cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Verdin <ver...@agrocampus-rennes.fr>
Subject Re: scripts XSLT et le cache
Date Thu, 05 Jan 2006 09:34:07 GMT
<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:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message