Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <601F6322AD71D5118D6C0003472515290660D1CC@sjmemexc1.stjude.org>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: [RT] Towards a new/another Forms Framework
Date: Tue, 1 Apr 2003 12:39:00 -0600 
MIME-Version: 1.0
Content-Type: text/plain

Bruno Dumon <bruno@outerthought.org> wrote:

> 
> It should be possible to create a form just by describing its 
> structure in an XML file (lets call this a "form 
> description"). I don't like the fact that for XMLForm/Struts 
> the user needs to write a bean just to hold the form data. 

We're currently doing something like this:  we've got a metadata model that
is mapped using a schema to a XML template that the users can modify to
create forms and other screens (eg; lists).  We've currently got a poorly
typed presentation syntax that gets mixed in with the object model created
from the metadata (it needs to have it's own schema but it's not yet a
priority).

Basically, in our model there are common presentation types that any object
can utilize.  Objects are metadata mappings of Java objects.  The creation
of the metadata object descriptions is driven from a database in our system,
but could be done with static XML descriptions (and was initially done this
way until the EJB's to get the stuff in and out of the database existed).
 
> (BTW, not using XML, XML validation, and XPath expressions as 
> request parameter names is a conscious choice, so what I'm 
> describing here is quite orthogonal to XMLForm, and leaning 
> more towards FormValidatorAction. XML will of course be used 
> extensively for publishing and configuration.)

By saying orthogonal I assume (hope) you're describing what you perceive as
a modeling requirement in _addition_ to XMLForm?  I don't think you want to
abandon XMLForm? It would seem to be good to have a standard way of
describing presentation semantics and I want to migrate our presentation
semantics to XMLForm in future versions of what we are doing...

> A form description would basically list all the "widgets" on 
> the form. Each widget would have an associated type (string, 
> date, long, decimal, ...), a number of validation rules, an 
> id, and other required configuration information depending on 
> the specific widget implementation. A form description would 
> be parsed ones into an object model, lets call this a 
> "FormDefinition". Based on this FormDefinition, a 
> FormInstance can be created, which is a lightweight 
> data-structure that holds the instance-specific data for the 
> form (the submitted values and the validation results). So 
> this would avoid the need to create a bean, since from the 
> user perspective, it would be as if the widgets themselves 
> hold their value.

I would encourage you to separate your presentation model, the object model
and the validation model.  We have one object model that can be reused in
multiple presentation contexts each requiring different combinations of
validation.

> Of course the kinds of widgets, validation rules, ... should 
> be defined by an interface so that anyone can provide 
> additional implementations.

Now you seem to be jumping from a XML meta model to a concrete Java
implementation?  I'm a bit confused what you're asking for?  I guess that's
your FormDefinition and FormInstance?  I wonder if perhaps you're jumping
from requirements to implementation a bit quickly here: you may not want to
have instantiate concrete data structures individually but rather use
generalized mappings (see below).

> For the rendering part, each widget-instance should be able 
> to produce an XML representation of itself. Then either a 
> generator or transformer approach can be used to generate or 
> merge-in the data.

We use aggregated generators (and Java composition in many cases): object
descriptions, presentation layout, validation each generated separately.
Seems to be working well: a generator is in most cases 20 - 30 lines of
code.  We then have an XSLT that smashes it all together into an abstract
object model at run time.  It's the hardest part, but really once you've
agreed on the schema it only needs to be written once and all pipelines
reuse it.  We separate the actual production of presentation into a separate
XSLT: in most cases producing HTML, in one case we generate SQL and DDL to
create a denormalized datamart for data analysis...

> The whole approach to think of a form as a set of widgets 
> that can themselves hold their value etc. also returns in JSF 
> (Java Server Faces), so that JSR can also be used for inspiration.
 
In our cases the data values are returned separately from the object values.
There are two main reasons for this:

1) we can cache the object creation for reuse with varying data;

2) the object model exploits XML hierarchy to represent object hierarchy.
Our data resides in many places not necessarily directly attached to the
object hierarchy and it would be computationally expensive (either at insert
or query time, take your pick) to maintain hierarchical data.  So we instead
return the data as flat (WRT to object hierarchy) XML.  Currently compound
object names based object hierarchy are then used to relate the data back to
the objects, but ultimately this should probably be by IDREF's...  Anyways,
the upshot is that by separating the two you can optimize the model
retrieval separately from the data retrieval.  I realize this isn't
necessarily conceptually clean, but IMHO it's the way to go; you can
reassemble the object representation combined with the data as needed.

> For those cases where the user just wants to make a form 
> above some database-table, EJB or Web-service, we could 
> introduce some mapping-concept that allows to map database 
> fields or EJB properties to widgets on the forms, so that 
> load and store operations can be done without any coding.

We currently use reflection on getters and setters to map object metadata
(what can I say, it's first release code).  That leads to very poorly
defined contracts (as Stephano would say). Next version should use parameter
maps all the way to the EJB's; though we're also playing with JDO it's not
clear it helps in our case.
 
> Some other things that should be possible with the form-framework:
>  * repeating (iterating) structures (to create tables etc.)

That can be (doesn't have to be) data driven: multiple data instances for an
object defining/restricting the presentation required.

>  * enabling/disabling widgets based on the values of other widgets.

This requires a presentation language all in itself: you verge on the
boundary of what flow is attempting to do...

>  * event handling: when user selects an item or changes a 
> value, do an automatic form submit and call an event handler 
> on the server

Again presentation language requirements.  You want to handle all events
(eg; onBlur: user side validation from server side generated Javascript)

>  * pose no requirements on the structure of URL's

You can't escape from HTTP that easily.... ;-)

>  * should be usable together with flowscript, but using 
> flowscript should not be a requirement

If you want some of the behaviors (dynamic widgets, event handling) you
should probably require it (or it's close cousin)...

>  * ...
> 
> All the above are as of yet only ideas, there's no code yet, 
> but once it gets this far I'd like to add it as a block to Cocoon CVS.
> 
> Thoughts?

We're playing with this a lot.  I'm still trying to determine where the
common ground between flow, XMLForm and our model is, but I don't think any
of them is exclusive of the other..