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 08:57:53 GMT
David Verdin wrote:
> Bonjour,
>
>>> Hé ! Hé ! C'est probable en effet. ;-)
>>> Malheureusement, ç'était un peu moins gadget : je cherche à 
>>> enregistrer des données de session, et de les intégrer dans des 
>>> fichiers identifiés par la date, pour éviter les monolithes.
>>
>> "monolithes" ? Euh... qu'est-ce que ça désigne ?
>
> Je veux éviter d'avoir de grosses pierres de plusieurs dizaines de 
> tonnes. Ça attire les druides et après on ne peut plus s'en 
> débarasser... ;-)      Désolé...
> Je veux éviter d'avoir des enregistrements successifs sans autres 
> information que leur contenu. Je veux pouvoir les identifier au moins 
> par leur date et donc les présenter différemment.
> Dans ce cadre, "monolithe" désignait - maladroitement, j'en conviens - 
> un gros fichier où tous les enregistrements s'enchainaient sans 
> identité propre. En fait, je peux très bien avoir un seul fichier, du 
> moment qu'à l'intérieur, chaque enregistrement est accompagné d'une date.

Par Toutatis, j'ai compris ! :-)


>> 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 :-)

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.

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.

<snip/>

>> Question bête : à quoi ça sert d'enregistrer les sessions ?
>
> Je réalise une site de test. En bref : on cherche du vocabulaire 
> susceptible d'être associé à celui utilisé par l'utilisateur dans sa 
> requête. Et l'objectif du site est de savoir si les solutions qu'on a 
> adoptées apportent un résultat satisfaisant.
> Donc j'enregistre la requête, les termes renvoyés, ceux que 
> l'utilisateur élimine, bref un peu tout ce qu'il fait au cours de sa 
> visite pour voir ce qui va et ce qui ne va pas.
> Tous les gens qui y participent sont prévenus qu'il s'agit d'un site 
> de test, bien sûr.

Ah, ok. Intéressant ! Je pensais que c'était pour reconstituer les 
sessions ultérieurement, et je ne comprenais pas bien.

> 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.

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