Le 9 avr. 05, � 10:46, Emmanuel FRANCISCO a �crit :
...<map:aggregate element="liste">
<map:part src="URL_SERVEUR/sourceXML" /> <map:part src="URL_SERVEUR/sourceXML1"/> <map:part src="URL_SERVEUR/sourceXML2"/>
...
...pour le moment il recupere toutes les donn�es du serveur m�me s'ils n'ont pas chang�. Est ce que c'est possible avoir une petite exemple? (car c'est toujours plus simple � comprendre avec un exemple :-) )...
Le m�canisme de cache interne est expliqu� dans http://cocoon.apache.org/2.1/userdocs/concepts/caching.html
Et Il y a un exemple qui explique assez bien le m�canisme (cl� + validit�) dans le bloc XSP, voir src/blocks/xsp/samples/java/cacheable.xsp (attention, XSP n'est plus recommand� pour de nouveaux projets, mais �a explique le principe).
Dans ton cas, avec
<map:part src="URL_SERVEUR/sourceXML" />
C'est le composant FileGenerator qui dit au pipeline combien de temps les donn�es sont valides (voir src/java/org/apache/cocoon/generation/FileGenerator.java).
Un moyen simple de fixer une dur�e de validit� configurable (pour autant que �a soit appropri� - l'essentiel est bien s�r que ce soit le serveur d'origine qui dise combien de temps les donn�es sont valides) serait de cr�er un g�n�rateur en h�ritant de FileGenerator et en surchargeant la m�thode getValidity pour retourner une constante configurable.
En fait, techniquement c'est l'objet Source qui d�finit la validit�, il y a peut-�tre un moyen encore plus simple...
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
