cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@digitalinsight.com>
Subject RE: [RT] Cocoon Input Model
Date Thu, 26 Feb 2004 21:50:49 GMT
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:gcasper@s-und-n.de] 
Sent:	Thursday, February 26, 2004 12:47 PM
To:	dev@cocoon.apache.org
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

Mime
View raw message