Daniel's message got me to thinking. In our case we don't really need the power of Cocoon forms as we are perfectly happy using XSLT to generate html. All we'd like is something a little better than the FormValidatorAction. I could easily see a new action that that invokes a pipeline to process the input parameters, much like the authentication framework does. I could visualize a generator that converts the request parameters into XML and then uses an XML Schema to validate them. Further transforms could then be used to further validate or transform the data. Ideally, the resulting XML could then be used to populate a Java object or just be passed on to other actions, etc.
Ralph -----Original Message----- From: Guido Casper [mailto:[EMAIL PROTECTED] Sent: Thursday, February 26, 2004 12:47 PM To: [EMAIL PROTECTED] Subject: Re: [RT] Cocoon Input Model 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. 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
