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.
Since AFAIK there is no standard DOM-like data model/API carrying strongly typed data we would have to come up with our own and I feel it might eventual look similar to the Woody widget hierarchy.
So what exactly is it that makes the Woody widget hierarchy unsuitable for being the data model of the inbound pipelining architecture?
Having said all that it ocurred to me that what you are describing is what in parts may correspond to an XForms-like architecture.
Ignoring for a moment that XForms is a client side technology and
thinking about the artifacts a developer has to create.
There is a form description which has its datatypes and validation rules
described by an XML Schema (IIUC). After data validation and everything
is done the data is sent to the server as a (weakly typed) XML document
which may be fed into a pipeline. When entering the pipeline the
document may be validated against the very same XML schema that
validates the form on the client-side. The XML flowing through the
pipeline is still weakly typed yet might be treated in a strongly typed
manner (such as the XPath 2.0 data model to be accessed by XSLT 2.0 or
XQuery or some super-duper XUpdate-like whatever next generation XML
manipulation language). However as it stands today there is no standard
way to access such a strongly typed data model (like XML schema's PSVI Post Schema Validation Infoset) via Java (AFAIK). Maybe XMLBeans (as Steven suggested) could help here?
So what about an XML-adaptor-like component (you could even today do a processPipelineToDOM("pipelineWithWoodyGenerator")) instead of changing Woody's internal data model?
Guido
