Maybe it is even better to have a source that can lookup mimeType, contentLength, inputStream from the context using JXPath expressions? Then one could use the ResourceReader to serve the content, and use the source in other places as well. The only difficult thing would be to configure the Xpath expressions... Would that be a good idea?
You could configure the source in the cocoon.xconf, specifying the JXPath expressions there. So yes, you could do it with a source. But I think they're better placed in the sitemap, thus as a reader.
Otherwise, you could have a source such as:
stream:/my/path/to/JXPath/Object(application/zip)
But that seems to be abusing the URL metaphor a bit too much for me.
Regards, Upayavira
-----Original Message----- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 11:47 AM To: [email protected] Subject: Re: Write binary data to output stream from flow
Bart Molenkamp wrote:
-----Original Message----- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, February 18, 2005 11:20 AM To: [email protected] Subject: Re: Write binary data to output stream from flow
Bart Molenkamp wrote:
Yes, it makes even better sense.
Would such a more generic, JXPath oriented stream reader be a
valuable
contribution to Cocoon?
To me it would. Anyone else think so, or have some reasons against?
In fact, the object you pass to the reader (via the XPath string), should not be the input stream, but some object that has a getInputStream method. That would make better sense.
If the object in the context is a bean, the path ./inputStream will
make
JXPath invoke getInputStream(), right? And the same for mimeType of course. So this leaves the user to make the decision if he passes an object which has a getInputStream() method, or if he passes the
stream
directly.
Guess so, yes. But it must be possible to configure the mime type manually via the sitemap as well as having it provided by the
flowscript.
Regards, Upayavira
