You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/12/19 11:48:09 UTC
StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
We have StreamGenerator. Which is in fact tied to Servlets!
This is incredible, if I want to get a stream from a request I have to
have Servlets!
We have a bunch of methods on the request, is there a reason that we
cannot get the inputstream? I don't see the real need of having it this
way, does anyone know if there was a reason for it?
BTW, this has in fact come out during the input pipelines discussion,
from a conceptual POV. I wasn't sure, so I dealt in the code and this is
what I found...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: examples of custom generators
Posted by Geoff Howard <co...@leverageweb.com>.
http://xml.apache.org/cocoon/tutorial/tutorial-generator.html
> -----Original Message-----
> From: Szymon Drejewicz [mailto:drejewic@wsisiz.edu.pl]
> Sent: Thursday, December 19, 2002 8:54 AM
> To: cocoon-dev@xml.apache.org
> Subject: examples of custom generators
>
>
>
> Hello,
>
> where can I find some examples of Cocoon generator?
>
> --
> Szymon Drejewicz
> drejewic@wsisiz.edu.pl
> drejewicz@idea.net.pl
> +48 502 566 085
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
examples of custom generators
Posted by Szymon Drejewicz <dr...@wsisiz.edu.pl>.
Hello,
where can I find some examples of Cocoon generator?
--
Szymon Drejewicz
drejewic@wsisiz.edu.pl
drejewicz@idea.net.pl
+48 502 566 085
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Nicola Ken Barozzi wrote:
>
> We have StreamGenerator. Which is in fact tied to Servlets!
>
> This is incredible, if I want to get a stream from a request I have to
> have Servlets!
>
> We have a bunch of methods on the request, is there a reason that we
> cannot get the inputstream? I don't see the real need of having it this
> way, does anyone know if there was a reason for it?
>
> BTW, this has in fact come out during the input pipelines discussion,
> from a conceptual POV. I wasn't sure, so I dealt in the code and this is
> what I found...
+1000 for adding getInputStream() to the Request interface.
/Daniel Fagerstrom
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
> Vadim Gritsenko wrote:
>
>> Nicola Ken Barozzi wrote:
>
[snip]
>>> 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:
<map:read
src="stream:=_mixed_007193FE85256C93_=/=_alternative_007193FE85256C93_="
mime-type="image/jpeg"/>
(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:
<body>
<xsp:logic>
for (Iterator i = streamModule.getAttributeNames().iterator();
i.hasNext();) {
<cinclude:include>
<xsp:attribute name="src"><xsp:expr>"stream:" + i.next()</xsp:expr>
</cinclude:include>
}
</xsp:logic>
</body>
Vadim
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
> Nicola Ken Barozzi wrote:
>
>>
>>
>> Vadim Gritsenko wrote:
>>
>>> Nicola Ken Barozzi wrote:
>>>
>>> [...]
>>>
>>>> Yes, I understood, I replied with the possibility of a source that
>>>> builds on the Request inputstream.
>>>
>>>
>>>
>>>
>>> Ok, what would be the InputStream for:
>>> (1) CommandLineEnvironment
>>> (2) JMSEnvironment
>>> (3) SMTPEnvironment
>>>
>>> [thinking process goes here]
>>>
>>> Possibilities:
>>> (1) Empty?
>>
>>
>>
>> The CLI environment can resolve the file and give that in the request,
>> as the servlet does.
>
> You lost me. What file request.getInputStream() should resolve to?
> Request is basically URL, and set of parameters (obtained from URL),
> there is no file in there.
Shit, this whole thing is getting me mixed up, right. So yes it's empty.
>>> (2) new StringBufferInputStream(textMessage.getText())?
>>
>> Yes, and extra stuff in the attributes.
>
> Request properties and/or attributes? And this will be work of
> environment to populate them.
It would be, yes...
>>> (3) mimeMessage.getContentStream() or
>>> ((Multipart)mimeMessage.getContent()).getBodyPart(0).getContentStream()?
>>
>> mimeMessage.getContentStream(), ie the raw mail.
>
> Basically, it will mean that somebody will have to implement mail
> parsing somewhere, and then get desired content (XML for the File- or
> StreamGenerator). Why not do this work in request itself?
IMHO in the Generator it would be more easily pluggable and doable.
Hmmm, I cannot really understand what advantage we may have in doing it
the request... I'm actually a bit ignorant on this requst stuff, and
don't understand it much, so it seems a hack to get round of using a
direct stream and generators. I would like to make Cocoon simpler, and
maybe this could be something of it? I really don't know unfortunately,
I'll have to stay with your opinion here till I know better.
But we should get away with the StreamGenerator anyway, and make a
source, no?
>>> Point is - before adding getInputStream() there is a need to
>>> understand what does it mean outside of servlet env.
>>
>> Yes, now I understand what you mean.
>
> :)
>
>>>>> Same place where MIME is decrypted and file attachments are processed.
>>>>
>>>>
>>>>
>>>> I don't understand what you want to do with the request factory here
>>>> If the Request interface doesn't have inputstream, it simply
>>>> doesn't, what would you like to do with the factory?
>>>
>>> Request i/face does not have inputstream right now, but it is still
>>> possible to process it - save files or read mime - thanks to request
>>> factories. Same here, if the only point is to read XML out of request
>>> input stream, this can be done in request factory and this XML could
>>> be saved as DOM object, as a request attribute(s) - same as FilePart
>>> is stored in the request now.
>>
>> Hmmm, what if I have to make Cocoon work as a transformation engine?
>> Every request contains the data to go to the generator... do I have to
>> buffer all the input in the request attributes?
>
>
> Or a file system (current implementation). Can you start request
> processing before fully reading request? I guess not, because to start
> processing sitemap you need to have all request parameters parsed.
Geez, you're right again. Very good point.
> To
> parse (POST-ed) parameters, you need to read body of the request, and if
> request is MIME, then request parameters could be in the last part of
> the MIME - thus, you will read up all attachements.
This sucks, but it's right.
> Do you see a workaround for this?
hehehe You still have hope, it seems. ;-)
Not giving request parameters if we get the stream directly , which
could somewhat be an option in cases where the stream is the only thing
that has the data. Do you think that in case of streams in some cases it
could be done without request parameters? Probably could be something to
investigate.
>>> For SMTPEnvironment, this can be several DOM objects - one per each
>>> MimePart containing XML, also you can save attachements the way it's
>>> done for servlet environment, and have plain text as request
>>> attributes too.
>>
>> But I want direct feed to the pipeline. This about using Cocoon as an
>> xml transformation engine, for example to adapt xml streams for
>> business xml processes. I ant to send the data to be processed to
>> Cocoon, not have to call Cocoon so that it calls me in turn and
>> processes my stuff =-)
>>
>> [...]
>>
>>>> I want to add a getInputStream() method to the Request interface.
>>>> And make a cocoon source to get it in the sitemap.
>>>
>>> If input stream works for all evironments, then it's the way to go.
>>> But I'm just not convinced yet.
>>
>> I understand what you mean. But I'm unconvinced of the opposite...
>> anyway, we can have both inputstream and request factory stuff. The
>> latter can also use the inputstream to be able to create attributes in
>> a lenient mode (ie only if requested).
>
> See above - there is a need to read whole request before starting sitemap.
Yup, in the general case, yes.
>> 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.
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.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
>
> Vadim Gritsenko wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>> [...]
>>
>>> Yes, I understood, I replied with the possibility of a source that
>>> builds on the Request inputstream.
>>
>>
>>
>> Ok, what would be the InputStream for:
>> (1) CommandLineEnvironment
>> (2) JMSEnvironment
>> (3) SMTPEnvironment
>>
>> [thinking process goes here]
>>
>> Possibilities:
>> (1) Empty?
>
>
> The CLI environment can resolve the file and give that in the request,
> as the servlet does.
You lost me. What file request.getInputStream() should resolve to?
Request is basically URL, and set of parameters (obtained from URL),
there is no file in there.
>> (2) new StringBufferInputStream(textMessage.getText())?
>
>
> Yes, and extra stuff in the attributes.
Request properties and/or attributes? And this will be work of
environment to populate them.
>> (3) mimeMessage.getContentStream() or
>> ((Multipart)mimeMessage.getContent()).getBodyPart(0).getContentStream()?
>
>
> mimeMessage.getContentStream(), ie the raw mail.
Basically, it will mean that somebody will have to implement mail
parsing somewhere, and then get desired content (XML for the File- or
StreamGenerator). Why not do this work in request itself?
>> Point is - before adding getInputStream() there is a need to
>> understand what does it mean outside of servlet env.
>
>
> Yes, now I understand what you mean.
:)
>>>> Same place where MIME is decrypted and file attachments are processed.
>>>
>>>
>>> I don't understand what you want to do with the request factory here
>>> If the Request interface doesn't have inputstream, it simply
>>> doesn't, what would you like to do with the factory?
>>
>>
>> Request i/face does not have inputstream right now, but it is still
>> possible to process it - save files or read mime - thanks to request
>> factories. Same here, if the only point is to read XML out of request
>> input stream, this can be done in request factory and this XML could
>> be saved as DOM object, as a request attribute(s) - same as FilePart
>> is stored in the request now.
>
>
> Hmmm, what if I have to make Cocoon work as a transformation engine?
> Every request contains the data to go to the generator... do I have to
> buffer all the input in the request attributes?
Or a file system (current implementation). Can you start request
processing before fully reading request? I guess not, because to start
processing sitemap you need to have all request parameters parsed. To
parse (POST-ed) parameters, you need to read body of the request, and if
request is MIME, then request parameters could be in the last part of
the MIME - thus, you will read up all attachements.
Do you see a workaround for this?
>> For SMTPEnvironment, this can be several DOM objects - one per each
>> MimePart containing XML, also you can save attachements the way it's
>> done for servlet environment, and have plain text as request
>> attributes too.
>
>
> But I want direct feed to the pipeline. This about using Cocoon as an
> xml transformation engine, for example to adapt xml streams for
> business xml processes. I ant to send the data to be processed to
> Cocoon, not have to call Cocoon so that it calls me in turn and
> processes my stuff =-)
>
> [...]
>
>>> I want to add a getInputStream() method to the Request interface.
>>> And make a cocoon source to get it in the sitemap.
>>
>>
>> If input stream works for all evironments, then it's the way to go.
>> But I'm just not convinced yet.
>
>
> I understand what you mean. But I'm unconvinced of the opposite...
> anyway, we can have both inputstream and request factory stuff. The
> latter can also use the inputstream to be able to create attributes in
> a lenient mode (ie only if requested).
See above - there is a need to read whole request before starting sitemap.
> 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.
> Let's continue this, please :-)
Sure :)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
> Nicola Ken Barozzi wrote:
>
> [...]
>
>> Yes, I understood, I replied with the possibility of a source that
>> builds on the Request inputstream.
>
>
>
> Ok, what would be the InputStream for:
> (1) CommandLineEnvironment
> (2) JMSEnvironment
> (3) SMTPEnvironment
>
> [thinking process goes here]
>
> Possibilities:
> (1) Empty?
The CLI environment can resolve the file and give that in the request,
as the servlet does.
> (2) new StringBufferInputStream(textMessage.getText())?
Yes, and extra stuff in the attributes.
> (3) mimeMessage.getContentStream() or
> ((Multipart)mimeMessage.getContent()).getBodyPart(0).getContentStream()?
mimeMessage.getContentStream(), ie the raw mail.
> Point is - before adding getInputStream() there is a need to understand
> what does it mean outside of servlet env.
Yes, now I understand what you mean.
>>> Same place where MIME is decrypted and file attachments are processed.
>>
>> I don't understand what you want to do with the request factory here
>> If the Request interface doesn't have inputstream, it simply doesn't,
>> what would you like to do with the factory?
>
> Request i/face does not have inputstream right now, but it is still
> possible to process it - save files or read mime - thanks to request
> factories. Same here, if the only point is to read XML out of request
> input stream, this can be done in request factory and this XML could be
> saved as DOM object, as a request attribute(s) - same as FilePart is
> stored in the request now.
Hmmm, what if I have to make Cocoon work as a transformation engine?
Every request contains the data to go to the generator... do I have to
buffer all the input in the request attributes?
> For SMTPEnvironment, this can be several DOM objects - one per each
> MimePart containing XML, also you can save attachements the way it's
> done for servlet environment, and have plain text as request attributes
> too.
But I want direct feed to the pipeline. This about using Cocoon as an
xml transformation engine, for example to adapt xml streams for business
xml processes. I ant to send the data to be processed to Cocoon, not
have to call Cocoon so that it calls me in turn and processes my stuff =-)
[...]
>> I want to add a getInputStream() method to the Request interface. And
>> make a cocoon source to get it in the sitemap.
>
> If input stream works for all evironments, then it's the way to go. But
> I'm just not convinced yet.
I understand what you mean. But I'm unconvinced of the opposite...
anyway, we can have both inputstream and request factory stuff. The
latter can also use the inputstream to be able to create attributes in a
lenient mode (ie only if requested).
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.
Let's continue this, please :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
[...]
> Yes, I understood, I replied with the possibility of a source that
> builds on the Request inputstream.
Ok, what would be the InputStream for:
(1) CommandLineEnvironment
(2) JMSEnvironment
(3) SMTPEnvironment
[thinking process goes here]
Possibilities:
(1) Empty?
(2) new StringBufferInputStream(textMessage.getText())?
(3) mimeMessage.getContentStream() or
((Multipart)mimeMessage.getContent()).getBodyPart(0).getContentStream()?
Point is - before adding getInputStream() there is a need to understand
what does it mean outside of servlet env.
>> Same place where MIME is decrypted and file attachments are processed.
>
>
> I don't understand what you want to do with the request factory here
> If the Request interface doesn't have inputstream, it simply doesn't,
> what would you like to do with the factory?
Request i/face does not have inputstream right now, but it is still
possible to process it - save files or read mime - thanks to request
factories. Same here, if the only point is to read XML out of request
input stream, this can be done in request factory and this XML could be
saved as DOM object, as a request attribute(s) - same as FilePart is
stored in the request now.
For SMTPEnvironment, this can be several DOM objects - one per each
MimePart containing XML, also you can save attachements the way it's
done for servlet environment, and have plain text as request attributes too.
[...]
>>>> Is there any justification for getInputStream() for non-servlet
>>>> environment?
>>>
>>>
>>> Simple example: web services. the request contains the data that I
>>> must process.
>>
>>
>> Bad example. It is servlet environment, again. It is not command line
>> or other environment.
>
>
> Good example. Web services are not done only on servlets. Messaging
> systems use asynch web services.
Ok, two examples are above - for JMS and SMTP. For mime mail message,
what part of the message do you want to stream?
> Component systems are not based on servlets. SOAP can go almost
> everywhere.
>
>>>> If no, I think it's better to try to encapsulate servlet-specific
>>>> logic into the factory.
>>>
>>
>> What's your take?
>
>
> Show me the code.
Suggestion about factory is above.
> I want to add a getInputStream() method to the Request interface. And
> make a cocoon source to get it in the sitemap.
If input stream works for all evironments, then it's the way to go. But
I'm just not convinced yet.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
> Nicola Ken Barozzi wrote:
>>
>> Vadim Gritsenko wrote:
>>
>>> Nicola Ken Barozzi wrote:
>>>>
>>>> We have StreamGenerator. Which is in fact tied to Servlets!
>>>
>>> What do you think - is it possible to eliminate StreamGenerator by
>>> adding some functionality to the RequestFactory?
>>
>> An InputStreamSource would be nice, so that any Generator can act on it.
>>
>> src="inputstream://"
>
> No, I've meant RequestFactory, from compontents.request package, not an
> input source.
Yes, I understood, I replied with the possibility of a source that
builds on the Request inputstream.
> Same place where MIME is decrypted and file attachments
> are processed.
I don't understand what you want to do with the request factory here
If the Request interface doesn't have inputstream, it simply doesn't,
what would you like to do with the factory?
>>>> This is incredible, if I want to get a stream from a request I have
>>>> to have Servlets!
>>>>
>>>> We have a bunch of methods on the request, is there a reason that we
>>>> cannot get the inputstream? I don't see the real need of having it
>>>> this way, does anyone know if there was a reason for it?
>>>
>>> Is there any justification for getInputStream() for non-servlet
>>> environment?
>>
>> Simple example: web services. the request contains the data that I
>> must process.
>
> Bad example. It is servlet environment, again. It is not command line or
> other environment.
Good example. Web services are not done only on servlets. Messaging
systems use asynch web services. Component systems are not based on
servlets. SOAP can go almost everywhere.
>>> If no, I think it's better to try to encapsulate servlet-specific
>>> logic into the factory.
>
> What's your take?
Show me the code. I want to add a getInputStream() method to the Request
interface. And make a cocoon source to get it in the sitemap.
What do you propose?
>>>
>>>> BTW, this has in fact come out during the input pipelines
>>>> discussion, from a conceptual POV. I wasn't sure, so I dealt in the
>>>> code and this is what I found...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
> Vadim Gritsenko wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> We have StreamGenerator. Which is in fact tied to Servlets!
>>
>>
>> What do you think - is it possible to eliminate StreamGenerator by
>> adding some functionality to the RequestFactory?
>
>
> An InputStreamSource would be nice, so that any Generator can act on it.
>
> src="inputstream://"
No, I've meant RequestFactory, from compontents.request package, not an
input source. Same place where MIME is decrypted and file attachments
are processed.
>>> This is incredible, if I want to get a stream from a request I have
>>> to have Servlets!
>>>
>>> We have a bunch of methods on the request, is there a reason that we
>>> cannot get the inputstream? I don't see the real need of having it
>>> this way, does anyone know if there was a reason for it?
>>
>>
>> Is there any justification for getInputStream() for non-servlet
>> environment?
>
>
> Simple example: web services. the request contains the data that I
> must process.
Bad example. It is servlet environment, again. It is not command line or
other environment.
>> If no, I think it's better to try to encapsulate servlet-specific
>> logic into the factory.
>
What's your take?
Vadim
>> Vadim
>>
>>
>>> BTW, this has in fact come out during the input pipelines
>>> discussion, from a conceptual POV. I wasn't sure, so I dealt in the
>>> code and this is what I found...
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> We have StreamGenerator. Which is in fact tied to Servlets!
>
> What do you think - is it possible to eliminate StreamGenerator by
> adding some functionality to the RequestFactory?
An InputStreamSource would be nice, so that any Generator can act on it.
src="inputstream://"
>> This is incredible, if I want to get a stream from a request I have to
>> have Servlets!
>>
>> We have a bunch of methods on the request, is there a reason that we
>> cannot get the inputstream? I don't see the real need of having it
>> this way, does anyone know if there was a reason for it?
>
> Is there any justification for getInputStream() for non-servlet
> environment?
Simple example: web services. the request contains the data that I must
process.
>If no, I think it's better to try to encapsulate
> servlet-specific logic into the factory.
>
> Vadim
>
>
>> BTW, this has in fact come out during the input pipelines discussion,
>> from a conceptual POV. I wasn't sure, so I dealt in the code and this
>> is what I found...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: StreamGenerator depends on Servlets!!! (input pipelines discussion
in concrete)
Posted by Vadim Gritsenko <va...@verizon.net>.
Nicola Ken Barozzi wrote:
>
> We have StreamGenerator. Which is in fact tied to Servlets!
What do you think - is it possible to eliminate StreamGenerator by
adding some functionality to the RequestFactory?
> This is incredible, if I want to get a stream from a request I have to
> have Servlets!
>
> We have a bunch of methods on the request, is there a reason that we
> cannot get the inputstream? I don't see the real need of having it
> this way, does anyone know if there was a reason for it?
Is there any justification for getInputStream() for non-servlet
environment? If no, I think it's better to try to encapsulate
servlet-specific logic into the factory.
Vadim
> BTW, this has in fact come out during the input pipelines discussion,
> from a conceptual POV. I wasn't sure, so I dealt in the code and this
> is what I found...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org