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:[EMAIL PROTECTED]
Autres commandes : mailto:[EMAIL PROTECTED]
