cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: StreamGenerator depends on Servlets!!! (input pipelines discussion in concrete)
Date Fri, 20 Dec 2002 16:32:44 GMT
Nicola Ken Barozzi wrote:

> Vadim Gritsenko wrote:
>> Nicola Ken Barozzi wrote:


>>> Also, the info to get the steam is conceptually in the environment, 
>>> not in the request factory that is used nevertheless by them. One 
>>> thing is getting the stream (inputstream), another is understanding 
>>> the pattern of the request.
>> But pattern of the request is tied to the environment - thus,the only 
>> good place to split request on parts is environment. Sitemap and 
>> sources can be used to process these parts, but parts extraction 
>> should happen in the environment.
> Ok, you are correct again IMO. Many systems use streams to trnsmit 
> stuff, but it's not necessarily like this in the general case.
> So yes, I again agree it should be in the environment.
> So, stepping a bit back to solve the initial problem... how can we 
> make this system be "generic" for all environments?
> RT: Maybe if every "part" that the request creates is gotten in the 
> sitemap as a source? Or as an inputmodule? For example, we can define 
> standard entries in the Request to get the parts that the environment 
> has gotten, like the inputstream one. Then we need to pipe it in the 
> Generator, or directly, or as an internal link to that points to the 
> resource in the request.

Continuing this RT:

Standardazing the streams in Request is good idea:
    int Request.getStreamCount();
    Collection Request.getStreamNames();
    InputStream Request.getStream(String name);

Source per request part idea also should work. HTML form with file input 
or text input can be used as:
    <map:read src="stream:formFileInput" mime-type="image/jpeg"/>
    <map:generate src="stream:formTextInput"/>

In SMTP environment, this might be:
(in string above note '/' symbol separating two boundaries) Hmm... I see 
the problem here with the nested streams... Could be solved if 
request.getStreamNames() returns all streams recursively.

Input module for "parts" might store ID to part name association - so 
you can get name of the stream in the sitemap. Thus,
    Collection StreamModule.getAttributeNames();
will return numbers, from 1 to count of streams ("parts") in the 
request, and
    Collection StreamModule.getAttributeValues();
will return names of the "parts". So, to get first text field or 
attachement name one can do:
    Collection StreamModule.getAttribute("1");
(this reminds of sitemap matchers) Usage in the sitemap then:
    <map:read src="stream:{stream:1}" mime-type="image/jpeg"/>

Continuing with this numbering idea... "0" might give access to the 
whole input stream - if possible...

So if you have HTML form with several XML files attached, you could 
actually aggregate them using XSP:
for (Iterator i = streamModule.getAttributeNames().iterator(); 
i.hasNext();) {
        <xsp:attribute name="src"><xsp:expr>"stream:" +</xsp:expr>


> A bit convoluted this description, I hope you understand. Can you help 
> me on this? I really want to remove that
> dependency for the StreamStuffthe on the servlet.

To unsubscribe, e-mail:
For additional commands, email:

View raw message