Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4215C796.9040906@upaya.co.uk>
Date: Fri, 18 Feb 2005 10:46:46 +0000
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041124)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Write binary data to output stream from flow
References: <5E091A68F794974CAF431CA31F5AF2CC11EA06@server.bizzdesign.nl>
In-Reply-To: <5E091A68F794974CAF431CA31F5AF2CC11EA06@server.bizzdesign.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Bart Molenkamp wrote:
> 
>>-----Original Message-----
>>From: Upayavira [mailto:uv@upaya.co.uk]
>>Sent: Friday, February 18, 2005 11:20 AM
>>To: dev@cocoon.apache.org
>>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