cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Cocoon Input Model
Date Fri, 05 Mar 2004 18:02:36 GMT
Sorry for dissapearing after having started this discussion.

Guido Casper wrote:
> 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.

I guess I was a little bit unclear. The typed DOM is only for storing
data in the application. The inbound dataflow is an ordinary Cocoon
pipeline, (SAX, untyped). There might be cases where one would like to
use validation and type info for the inbound data, but I think that
should be done within the pipeline component, not in the communication
between them.

                           --- O ---

Steping back a little bit, the main point with my RT was to discuss
design patterns for webapps (or more generally Cocoon based applications
in all supported environments), rather than any sitemap extensions or
the like. All that I proposed can be done within the current Cocoon, I
am not proposing any new mechanisms, (although some stuff possibly could
be done in a more convinient way with new sitemap constructs).

So, a webapp consist of a controller for multi page flow or workflow
(flowscripts). In each step in the flow input is read, an internal state
is updated and output is produced. We all agree about that output
production should be XML based. My main message is that it is a good
idea to use XML for the inbound dataflow and at least to a part as a
storage to.

For the input part this can be done by calling a pipeline with the
processPipelineTo[...] function in flowscripts. The pipeline typically
starts with a stream or request generator or any generator that reads
from a module source connected to an input stream or something similar.

The state consist typically of a backend (DB, EJB etc) and some session
state (session attributes, flowscript variables). For form handling it
is a good design pattern to store input data in a "form model" instead
of writing dirrectly to the backend. Especially if the backend is of
transactional nature. This pattern is used in CForms. The form model is
a (typically typed) data structure where you gather the input before
writing it to the backend. In update operations, the form model is also
loaded with data from the backend before it is "edited" through the web gui.

What I propose is that the "form model" idea is not only usable in
CForms based form handling but in other kinds of webapps as well. So it
would be practical if the utilities for handling some appropriate typed
datastructure was made available outside CForms. Thus the mechanisms for
loading data (XML, Java beans, DB etc) into the store and saving from it
could be reused in other contexts also.

To work well with the rest of Cocoon, XML seem to be the most practical

> 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.

You are AFAIK right in that there are no standard API for accessing type
info or detailed validation info. There is a standard: for checking 
what element you can add on a point in a tree and a note on accessing 
schema info. Both are IMO overkill for our current needs. What we need 
is adding a schema to a DOM, perform a validation of the DOM, ask a text 
node or attribute for what shema data type it has, if it is valid and 
geting it content in term of a Java object.

So even if we would need some properitary enhancments, we can still use 
DOM core, events, XMLSchema, Relax-NG etc, and implementations of them. 
The data type part of the different schema languages is desiged just for 
creating the strong type system for XML that is needed for dewscribing 
data to/from databases, programs etc.

My point is actually that the storage aspect of the widget hierarchy 
have so many similaritites with typed XML that it seem to be a masive 
re-invention of the wheel to have an own propitary solution with an own 
schema language, own data types, own api etc.

> So what exactly is it that makes the Woody widget hierarchy unsuitable
> for being the data model of the inbound pipelining architecture?

The main problem is the impedance mismatch with XML. As soon as you want 
to go from widgets to XML or back, you have to write a binding for this.

> Having said all that it ocurred to me that what you are describing is
> what in parts may correspond to an XForms-like architecture.

It certainly does, that was one of the inspiration sources. Forgot to 
refer to it.

> 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).

Yes, something like that!

> 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?

As said above, all the untyped aspects of the data structure can be used 
through the DOM interfaces, but we need some propitary extensions for 
the type and validation info.

> So what about an XML-adaptor-like component (you could even today do a 
> processPipelineToDOM("pipelineWithWoodyGenerator")) instead of changing 
> Woody's internal data model?

Yes, having a DOM facade to the widget hierarchy is one way to realise 
what I propose. I believe that there are good reasons for have a 
stronger speration of concern whithin CForms between the data store and 
the control aspects of widgets, but I return to that in more detail later.


View raw message