* Guido Casper <[EMAIL PROTECTED]> [2004-02-26 20:41]:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g -> t* -> store -> act -> [select] -> g -> t* -> s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow seems to be too different from those of outbound data flow.
For outbound data flow everything is converted to a string which is quite easy and nicely supported by XML's weakly typed nature (IMO one major reason for XMLs power and success) and a powerful transformation language.
For inbound data flow (as you already mentioned) you need strongly typed data which requires parsing, validation and error handling. I do see value in putting this data - once grabbed and converted by the forms framework - into some sort fo pipeline. What I'm unsure about is if these pipelines will be of similar power as weakly typed pipelines. I believe Cocoon's pipelines achieve this level of component reusability because of its weakly typed (and therefore loosely coupled) nature.
Now IIUC you suggest a pipelining architecture for inbound data flow with a DOM-like data model.
What do you mean by strongly typed? Are we discussiong form posts here?
Yes, form posts being the use case at hand, but there are other ways input may be provided. Quoting Daniel:
>>>
Besides using request parameters and "structured" request parameters as user input. XML is used for WebDAV and web service applications, XML are also becoming more common from more advanced user clients. And with new environments like mail, CLI, JMS and possibly more, we will get even more user input formats.
<<<
Guido
For some time now, I've wondered how one would post XML to Cocoon and start out with it in the pipeline. Cocoon would make short work of REST implementations.
(Trying to get up to speed.)
