You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-fr@cocoon.apache.org by David Verdin <ve...@agrocampus-rennes.fr> on 2006/01/04 15:45:38 UTC
scripts XSLT et le cache
Bonjour,
J'utilise Cocoon *2.1.5.1 *sur Tomcat 5.0.28.
J'utilise des scripts XSLT pour générer mes pages, que ce soit les
scripts fournis dans les samples pour la mise en page, ou bien des
scripts perso.
Dans tous, les cas, je constate que le script n'est pas systématiquement
rechargé par Cocoon lors de son utilisation. En d'autres termes : il
reste identique dans le cache, même quand cela ne devrait pas être le cas.
J'ai lu la doc du système de cache de Cocoon, et il apparaît que les
fichiers en cache ne sont relus depuis la source que si leur date de
modification a changé. Système qui semble logique, puisqu'il évite de
relire un fichier inchangé.
Les problèmes que j'observe sont :
1- Les fichiers appelés lors de l'utilisation d'une balise
<xsl:include/> ne sont pas rechargés après leur modification, mais
seulement après modification du fichier xsl qui est utilisé par le
sitemap et qui les appelle. Par exemple, «
forms-advanced-field-styling.xsl » est appelé par «
forms-samples-styling.xsl ». Ce dernier est utilisé dans le sitemap pour
mettre en page les formulaires. Si on modifie «
forms-advanced-field-styling.xsl » seul, les modifications ne seront pas
prises en compte, à moins que l'on modifie « forms-samples-styling.xsl »
où que l'on recharge Cocoon, ou bien qu'on vide le cache.
2- Certaines expressions ne sont pas réévaluées à l'intérieur d'un
script dont le fichier n'a pas été modifié. J'utilise ainsi la fonction
date:date() d'EXSLT, implémentée par xalan. Après la première
utilisation du script par Cocoon, la date n'est plus modifiées, à moins
de réinitialiser le cache.
Je souhaiterais donc me débarasser de la mise en cache des scripts XSLT,
mais sans pour autant supprimer l'utilisation du cache pour tout le
pipeline : ça peut être utile pour le images, les CSS, enfin plein
d'autres types de fichiers utilisés dans le pipeline et pour qui le
système de cache fonctionne très bien !
Avez-vous des indices ?
À bientôt !
David Verdin
---------------------------------------------------------------------
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
Re: scripts XSLT et le cache
Posted by David Verdin <ve...@agrocampus-rennes.fr>.
Sylvain Wallez wrote:
>
> 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 !!
Tout à fait d'accord. Pour soi et pour ceux qui reprendront le système
dans un an...
>
> 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.
Je vais regarder ça.
> 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.
>
Merci pour toutes ces informations bien utiles et cette remise en
perspective des fonctions de Cocoon.
J'essaierai d'apporter ma propre contribution le jour où j'aurai quelque
chose de nouveau !
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
Re: scripts XSLT et le cache
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: scripts XSLT et le cache
Posted by David Verdin <ve...@agrocampus-rennes.fr>.
<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
Re: scripts XSLT et le cache
Posted by Frédéric Glorieux <fr...@ajlsm.com>.
Merci beaucoup pour cette explication très justifiée du flowscript, pour
lequel je suis encore très réticent, du moins dans sa version
javascript. L'aspect qui me dérange toujours est d'aller fouiller des
API java pour deviner comment dire en javascript ce qui est à l'origine
en JAVA. Javaflow est certainement ce qui me concernera pour la release
cocoon 2.2
> 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,
Partageant ce constat, j'utilise souvent les actions xsp, en compilation
temps réel comme du script ou leurs soeures générateur. Est-ce aussi à
ranger dans les mauvaises pratiques ?
--
Frédéric Glorieux (AJLSM, http://ajlsm.com)
---------------------------------------------------------------------
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
Re: scripts XSLT et le cache
Posted by Sylvain Wallez <sy...@apache.org>.
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
Re: scripts XSLT et le cache
Posted by David Verdin <ve...@agrocampus-rennes.fr>.
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.
>
>> Alors j'utilise le code suivant dans un XSL :
>>
>> <xsl:template match="/">
>> <racine xmlns:source="http://apache.org/cocoon/source/1.0">
>> <source:insert>
>>
>> <source:source>context://documents/historiqueRequetes/<xsl:value-of
>> select="substring-before(date:date(),'+')"/>session.xml</source:source>
>> <source:fragment>
>> <session:getxml context="ontoRequete" path="/"/>
>> </source:fragment>
>> <source:path>/racine</source:path>
>> </source:insert>
>> </racine>
>> </xsl:template>
>
>
> 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 ?
>
>> Ceci est utilisé dans ce pipeline :
>>
>> <map:match pattern="sauverRequete">
>> <map:generate src="fragmentSession.xml"/> <!-- Un fichier
>> pipeau -->
>> <map:transform
>> src="context://documents/resources/enregistreurSession.xsl"/> <!--
>> mon XSLT -->
>> <map:transform type="session"/>
>> <map:transform type="write-source"/>
>> <map:serialize type="xml"/>
>> </map:match>
>> Et paf ! on insère dans un fichier XML les infos de session. Si
>> le fichier n'existe pas, on le crée. Et la date est sensée changer
>> tous les jours.
>
>
> Ok. Vu que c'est un pipeline dont le résultat va toujours changer, tu
> peux le mettre dans un <map:pipeline type="non-caching">.
Ah ben c'est vrai ça.
Je vais essayer !
>
> Tu peux aussi passer la date en paramètre de la xsl avec un
> <map:parameter name="date" value="{date:yyyyMMdd}"/>
Argh... Je ne le connaissais pas ce paramètre-là...
Sinon j'aurais évité les expressions XSLT exotiques et pas encore bien
reconnues...
>> Une solution sera peut-être de vider le cache tous les jours à 0h01...
>> Cela dit, il existe peut-être une autre solution pour enregistrer les
>> sessions.
>
>
> 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.
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.
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
Re: scripts XSLT et le cache
Posted by Sylvain Wallez <sy...@apache.org>.
David Verdin wrote:
> Merci pour cette réponse !
> J'ai une ou deux remarques...
>
> Sylvain Wallez wrote:
<snip/>
>> Si c'est pour afficher l'heure dans la page web, mon humble avis est
>> que l'utilisateur a fort probablement l'heure sur son écran, sa
>> montre, son télephone portable, voire l'horloge accrochée au mur :-)
>
> 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 ?
> Alors j'utilise le code suivant dans un XSL :
>
> <xsl:template match="/">
> <racine xmlns:source="http://apache.org/cocoon/source/1.0">
> <source:insert>
>
> <source:source>context://documents/historiqueRequetes/<xsl:value-of
> select="substring-before(date:date(),'+')"/>session.xml</source:source>
> <source:fragment>
> <session:getxml context="ontoRequete" path="/"/>
> </source:fragment>
> <source:path>/racine</source:path>
> </source:insert>
> </racine>
> </xsl:template>
Argh, le fameux SourceWritingTransformer...
> Ceci est utilisé dans ce pipeline :
>
> <map:match pattern="sauverRequete">
> <map:generate src="fragmentSession.xml"/> <!-- Un fichier
> pipeau -->
> <map:transform
> src="context://documents/resources/enregistreurSession.xsl"/> <!-- mon
> XSLT -->
> <map:transform type="session"/>
> <map:transform type="write-source"/>
> <map:serialize type="xml"/>
> </map:match>
> Et paf ! on insère dans un fichier XML les infos de session. Si le
> fichier n'existe pas, on le crée. Et la date est sensée changer tous
> les jours.
Ok. Vu que c'est un pipeline dont le résultat va toujours changer, tu
peux le mettre dans un <map:pipeline type="non-caching">.
Tu peux aussi passer la date en paramètre de la xsl avec un
<map:parameter name="date" value="{date:yyyyMMdd}"/>
> Une solution sera peut-être de vider le cache tous les jours à 0h01...
> Cela dit, il existe peut-être une autre solution pour enregistrer les
> sessions.
Question bête : à quoi ça sert d'enregistrer les sessions ?
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
Re: scripts XSLT et le cache
Posted by David Verdin <ve...@agrocampus-rennes.fr>.
Merci pour cette réponse !
J'ai une ou deux remarques...
Sylvain Wallez wrote:
> David Verdin wrote:
>
>> Bonjour,
>>
>> J'utilise Cocoon *2.1.5.1 *sur Tomcat 5.0.28.
>>
>> J'utilise des scripts XSLT pour générer mes pages, que ce soit les
>> scripts fournis dans les samples pour la mise en page, ou bien des
>> scripts perso.
>>
>> Dans tous, les cas, je constate que le script n'est pas
>> systématiquement rechargé par Cocoon lors de son utilisation. En
>> d'autres termes : il reste identique dans le cache, même quand cela
>> ne devrait pas être le cas.
>>
>> J'ai lu la doc du système de cache de Cocoon, et il apparaît que les
>> fichiers en cache ne sont relus depuis la source que si leur date de
>> modification a changé. Système qui semble logique, puisqu'il évite de
>> relire un fichier inchangé.
>>
>> Les problèmes que j'observe sont :
>>
>> 1- Les fichiers appelés lors de l'utilisation d'une balise
>> <xsl:include/> ne sont pas rechargés après leur modification, mais
>> seulement après modification du fichier xsl qui est utilisé par le
>> sitemap et qui les appelle. Par exemple, «
>> forms-advanced-field-styling.xsl » est appelé par «
>> forms-samples-styling.xsl ». Ce dernier est utilisé dans le sitemap
>> pour mettre en page les formulaires. Si on modifie «
>> forms-advanced-field-styling.xsl » seul, les modifications ne seront
>> pas prises en compte, à moins que l'on modifie «
>> forms-samples-styling.xsl » où que l'on recharge Cocoon, ou bien
>> qu'on vide le cache.
>
>
> C'est exact. Cette mise en cache "aggressive" est liée au fait que
> contrôler la validité de l'ensemble des XSLs incluses est coûteuse. Un
> moyen d'éviter cela est de supprimer la mise en cache des XSLs, en
> mettant <use-store>false</use-store> dans l'élément <xslt-processor>
> de cocoon.xconf.
>
> Par contre, cela a un impact non négligeable sur les performances,
> puisque les XSLs sont réinterprétées à chaque utilisation.
Oui, c'est bien ce qui m'ennuie. Je suis bien conscient de l'intérêt du
cache. Évidemment, ce serait bien si on pouvait signaler, au cours du
déroulement d'un pipeline, l'utilisation ou non du cache.
Évidemment, ça ferait un paramètre en plus à interpréter lors de la
lecture du sitemap... Je ne sais pas ce qui coûte le plus cher : ne pas
utiliser le cache ou demander de vérifier s'il faut s'en servir pour
chaque ligne du pipeline.
>
>> 2- Certaines expressions ne sont pas réévaluées à l'intérieur d'un
>> script dont le fichier n'a pas été modifié. J'utilise ainsi la
>> fonction date:date() d'EXSLT, implémentée par xalan. Après la
>> première utilisation du script par Cocoon, la date n'est plus
>> modifiées, à moins de réinitialiser le cache.
>
>
> C'est un autre problème: Cocoon conserve la production d'un pipeline
> en cache si les condition de validité de ce pipeline sont vérifiées.
> Dans le cas de XSL, la validité est définie par la modification de la
> XSL et les valeurs des paramètres passés à la XSL. La date calculée
> avec date:date() est inconnue du système de pipeline, et n'est donc
> pas prise en compte par le système de cache.
> Pour résoudre ce problème, il faut utiliser un pipeline sans cache,
> avec <map:pipeline type="non-caching"> dans la sitemap. Mais là
> encore, l'impact est non-négligeable puisque le cache n'est plus utilisé.
Effectivement. Donc, l'alternative est : soit tout ce qui est variable
est passé en paramètre au sein du pipeline, soit on n'utilise pas du
tout le cache pour XSLT, ce qui force Cocoon à tout vérifier. C'est ça ?
>> Je souhaiterais donc me débarasser de la mise en cache des scripts
>> XSLT, mais sans pour autant supprimer l'utilisation du cache pour
>> tout le pipeline : ça peut être utile pour le images, les CSS, enfin
>> plein d'autres types de fichiers utilisés dans le pipeline et pour
>> qui le système de cache fonctionne très bien !
>
> Le cache n'est réellement utile que pour les pipelines. Les images et
> les CSS sont purement statiques et ne subissent aucun traitement. Je
> serais plutôt d'avis de supprimer date:date() des XSLs!
Ah bon ?
Argh, j'ai encore lu trop vite...
> Si c'est pour afficher l'heure dans la page web, mon humble avis est
> que l'utilisateur a fort probablement l'heure sur son écran, sa
> montre, son télephone portable, voire l'horloge accrochée au mur :-)
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. Alors j'utilise le code suivant
dans un XSL :
<xsl:template match="/">
<racine xmlns:source="http://apache.org/cocoon/source/1.0">
<source:insert>
<source:source>context://documents/historiqueRequetes/<xsl:value-of
select="substring-before(date:date(),'+')"/>session.xml</source:source>
<source:fragment>
<session:getxml context="ontoRequete" path="/"/>
</source:fragment>
<source:path>/racine</source:path>
</source:insert>
</racine>
</xsl:template>
Ceci est utilisé dans ce pipeline :
<map:match pattern="sauverRequete">
<map:generate src="fragmentSession.xml"/> <!-- Un fichier pipeau -->
<map:transform
src="context://documents/resources/enregistreurSession.xsl"/> <!-- mon
XSLT -->
<map:transform type="session"/>
<map:transform type="write-source"/>
<map:serialize type="xml"/>
</map:match>
Et paf ! on insère dans un fichier XML les infos de session. Si le
fichier n'existe pas, on le crée. Et la date est sensée changer tous les
jours.
Une solution sera peut-être de vider le cache tous les jours à 0h01...
Cela dit, il existe peut-être une autre solution pour enregistrer les
sessions.
Merci de ta réponse, de toutes façons !
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
Re: scripts XSLT et le cache
Posted by Sylvain Wallez <sy...@apache.org>.
David Verdin wrote:
> Bonjour,
>
> J'utilise Cocoon *2.1.5.1 *sur Tomcat 5.0.28.
>
> J'utilise des scripts XSLT pour générer mes pages, que ce soit les
> scripts fournis dans les samples pour la mise en page, ou bien des
> scripts perso.
>
> Dans tous, les cas, je constate que le script n'est pas
> systématiquement rechargé par Cocoon lors de son utilisation. En
> d'autres termes : il reste identique dans le cache, même quand cela ne
> devrait pas être le cas.
>
> J'ai lu la doc du système de cache de Cocoon, et il apparaît que les
> fichiers en cache ne sont relus depuis la source que si leur date de
> modification a changé. Système qui semble logique, puisqu'il évite de
> relire un fichier inchangé.
>
> Les problèmes que j'observe sont :
>
> 1- Les fichiers appelés lors de l'utilisation d'une balise
> <xsl:include/> ne sont pas rechargés après leur modification, mais
> seulement après modification du fichier xsl qui est utilisé par le
> sitemap et qui les appelle. Par exemple, «
> forms-advanced-field-styling.xsl » est appelé par «
> forms-samples-styling.xsl ». Ce dernier est utilisé dans le sitemap
> pour mettre en page les formulaires. Si on modifie «
> forms-advanced-field-styling.xsl » seul, les modifications ne seront
> pas prises en compte, à moins que l'on modifie «
> forms-samples-styling.xsl » où que l'on recharge Cocoon, ou bien qu'on
> vide le cache.
C'est exact. Cette mise en cache "aggressive" est liée au fait que
contrôler la validité de l'ensemble des XSLs incluses est coûteuse. Un
moyen d'éviter cela est de supprimer la mise en cache des XSLs, en
mettant <use-store>false</use-store> dans l'élément <xslt-processor> de
cocoon.xconf.
Par contre, cela a un impact non négligeable sur les performances,
puisque les XSLs sont réinterprétées à chaque utilisation.
> 2- Certaines expressions ne sont pas réévaluées à l'intérieur d'un
> script dont le fichier n'a pas été modifié. J'utilise ainsi la
> fonction date:date() d'EXSLT, implémentée par xalan. Après la première
> utilisation du script par Cocoon, la date n'est plus modifiées, à
> moins de réinitialiser le cache.
C'est un autre problème: Cocoon conserve la production d'un pipeline en
cache si les condition de validité de ce pipeline sont vérifiées. Dans
le cas de XSL, la validité est définie par la modification de la XSL et
les valeurs des paramètres passés à la XSL. La date calculée avec
date:date() est inconnue du système de pipeline, et n'est donc pas prise
en compte par le système de cache.
Pour résoudre ce problème, il faut utiliser un pipeline sans cache, avec
<map:pipeline type="non-caching"> dans la sitemap. Mais là encore,
l'impact est non-négligeable puisque le cache n'est plus utilisé.
> Je souhaiterais donc me débarasser de la mise en cache des scripts
> XSLT, mais sans pour autant supprimer l'utilisation du cache pour tout
> le pipeline : ça peut être utile pour le images, les CSS, enfin plein
> d'autres types de fichiers utilisés dans le pipeline et pour qui le
> système de cache fonctionne très bien !
Le cache n'est réellement utile que pour les pipelines. Les images et
les CSS sont purement statiques et ne subissent aucun traitement. Je
serais plutôt d'avis de supprimer date:date() des XSLs!
Si c'est pour afficher l'heure dans la page web, mon humble avis est que
l'utilisateur a fort probablement l'heure sur son écran, sa montre, son
télephone portable, voire l'horloge accrochée au mur :-)
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