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 Wed, 04 Jan 2006 15:36:06 GMT
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


Mime
View raw message