Hi guys, Thanks for your ideas. Geert, creating a list of all image URLs in a an XML file may not work for this project because our list of images (content) is dynamic and keeps on changing. Someone may remove/add/update the content files daily.
Conal, I will try out your idea. I hope performance is not an issue as Cocoon will have to check for physical file every time it encounters an image URL. But I will test it out and let you guys know. Also, the other idea I had was to use an XSP page using Java and then use standard Java File I/O. But looks like XSP can only be used as a 'generator' which is difficult in my case. The transformation starts off with a source XML file. And I can get the image URLS only after a 2nd pass of transformations using XSL. Anyways, I will send you a update soon! Thanks again! Hiral -----Original Message----- From: Geert Josten [mailto:[EMAIL PROTECTED] Sent: Thursday, February 17, 2005 4:16 AM To: [email protected] Subject: Re: XSL File I/O > See this faq about using XSLT document() in Cocoon, which includes a > mention of this bug: > http://cocoon.apache.org/2.0/faq/faq-xslt.html#faq-6 > > This is the "cacheability" problem referred to: > > when you execute an XSLT transform that calls the "document('foo.xml')" > method, the date stamp of the file foo.xml is not included in the > CacheValidity of the transform. So even after you modify foo.xml, the > pipeline will continue to serve the cached results. > > Cheers > Con Ah! That explains some strange behaviour I experienced. Does it help to put the XML broking pipe in a non-caching pipeline? Cheers, Geert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
