cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: scripts XSLT et le cache
Date Thu, 05 Jan 2006 10:12:04 GMT
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:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message