Vadim Gritsenko wrote:
The CLI environment can resolve the file and give that in the request, as the servlet does.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())?
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.
Hmmm, what if I have to make Cocoon work as a transformation engine?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.I don't understand what you want to do with the request factory hereSame place where MIME is decrypted and file attachments are processed.
If the Request interface doesn't have inputstream, it simply doesn't, what would you like to do with the factory?
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 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).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.
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
