> > Hmm... c'est un bug dans la doc. Le transformer i18n *est* cachable.
> J'aurais pourtant pu le vérifier facilement.
sauf erreur il me semble que le StatusGenerator affiche l'état du
cache de Cocoon, assez pratique pour voir ce qui est caché ou pas.
laurent
(qui a cassé ledit generator en remp
Si j'ai compris, pour le cas xsl, cela rentre dans la clé de cache du
tuyau concerné, au pire on multiplie le nombre de flux sax par le
nombre de langues demandées ?
Est-ce vraiment "au pire" ?
Pardon, "le mieux c'est que..."
Le fonctionnement du cache de Cocoon permet
d'avoir grâce à ce
Frédéric Glorieux wrote:
- Donc par example il vaut mieux eviter la locale action a
l'interieur d'un pipeline et la mettre a l'exterieur des "match
pattern" ?
Ca ne change rien, puisque le pipeline est *toujours* assemblé et les
structures de contrôle sont *toujours* exécutées. En effet, le
- Donc par example il vaut mieux eviter la locale action a l'interieur
d'un pipeline et la mettre a l'exterieur des "match pattern" ?
Ca ne change rien, puisque le pipeline est *toujours* assemblé et les
structures de contrôle sont *toujours* exécutées. En effet, le calcul de
la clé de cache
la XSP. Donc on économise un peu de temps d'exécution, bien que
dans ce cas ça ne soir probablement pas sensible.
- Parfois un pipeline n'est pas cachable dans sa globalite mais les
1ers elements le sont. Donc cela vaut la peine d'au moins recuperer ce
qui a ete cache dans les 1
fois un pipeline n'est pas cachable dans sa globalite mais les
1ers elements le sont. Donc cela vaut la peine d'au moins recuperer ce
qui a ete cache dans les 1eres etapes?
Oui, puisque le pipeline "caching" met en cache l'entrée du premier
composant non cachable, de
Bonsoir,
Je voulais connaitre vos avis/valider ce que je crois comprendre sur le
cache des pipelines :
- Etant sur qu'un pipeline n'est pas cachable (example XSP de base), je
pense qu'il vaut mieux le sortir de la section type="caching"> pour une section , pour
eviter un check systematique d
