cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject RE: [RT] forms
Date Fri, 20 Jul 2001 12:39:41 GMT
> >Looking at all the approaches for xml based form handling
> >(including my own ones) I'm not really happy what there
> >is available up to now...
> >
> >Especially multipage forms, error messages and i18n
> >is not addressed in an extensive or sufficient manner.
> >
> >The Model:
> >What we do so far is to have a business object that
> >represent the whole mulitpage form:
> our objects to be filled in are much more complex than this,
> we are often dealing with Composite Beans, ie, Beans that can contain
> Beans. The Properties on the Beans also have Editors that do the getting,
> setting and Validation.
> Simple Properties
> Simple Indexed Properties
> Composite Properties
> Composite Indexed Properties
> Nested Composite Indexed Properties ;)
> Property Attributes
> Our current idea is to use the form field name as an 'address' into the
> Bean, ripping off the syntax from XPath. So that the TagLib can 'auto-fill'
> the Bean from the form.
> one/two/three 										- address a simple property
> one/two/three[3] 									- address an item within a simple
> 		indexed property
> one/two[2]/three[4]/four 					- address a property of an indexed
> 		composite property
> one/two/three/@negotiable 				- address a simple property's 'attributes'
> one/two[2]/three[4]/@negotiable 	- address an attribute of an indexed property
> one/two[1]/four[0]/eek 						- address a property of a nested
> 		indexed composite property
> one/two[1]/four[0]/eek/@required 	- address an attribute of property of
> 		a nested indexed composite property

This is indeed a nice idea. But maybe this is possible
with currently discussed approach. Let's assume we have
the interface:

interface DOMObject extends XMLFragment {
  void setValue( String XPath );
  String getValue( String XPath );

We could create different types of mappers or

class BeanDOM implements DOMObject {
  void setValue( String XPath ){
    /* write to your framework */
  String getValue( String XPath ){
    /* read from your framework */

That's what I intended to do for my business objects
anyway! (although this is not comforming to the XForm spec)
But for complex business logic and as "frontend" to
a framework this much nicer than the XForm approach
that there is right now.

> >The Controler:
> >We have a Populator that populates the posted
> >values into the correct OrderForm fields
> >and a Validator that check all involved fields
> >on validity. The result is passed to the
> >Selector that select the new view/page.
> This is where I would like to be able to generate an Action from XSP
> TagLibs, as I think you are beginning to want as well.

I always wanted :)

> Because the TagLib for the Crudlet Engine was developed originally for
> Cocoon 1, it has all the functionality to be able to generate and handle
> forms, multi page etc., now with Cocoon 2, we can usefully split generation
> and handling into smaller reusable components via the SiteMap/FlowMap, it
> would be of tremendous advantage to be able to re-use the XSP Languages
> that have already been developed (esql, auth, fp, crudlet etc.).
> Any way, I commend your attempt!
> I would certainly like to work the MVC Pattern more rigorously into our
> approach.

Thanks, took a while to find a way - but I'm still not satisfied as you
might see ;) too much java programming required for the forms

> The problem I see is that people have developed different languages for
> different storage mediums, hence we have esql -> SQL DB, fp -> XML File,
> crudlet -> JavaBeans/JavaSpace, and many others.
> How do we provide a way to make a generic form handling and verification
> system that can easily deal with different storage?
> I am convinced XSP Actions would help.

I was always voting for makeing the XSPEngine a component that can be
used not just for the generation of cocoon serverpages. I would have
used this engine to create some classes for my application via XSP
as well!! And of course it could be used easily to create XSP based
Actions! Just a different stylesheet and a different class name
convention - maybe a different output dir.

Undreamed-of possibilities!

> BTW. The other big problem I am wrestling with is the thorny issue of
> content-logic; where the content that is displayed is intricately tied to
> the condition of runtime and static parameters, often in our case up to
> four or five levels of nested if-then-else 'statements'. We find this
> content-logic to be in a different realm to the underlying business-logic
> of the Beans, it needs to be accessible to the Content Authors as they are
> the ones who understand the logic and the content at the display level.
> This does not map nicely into the Cocoon "cleanroom" model.

I can have a slight idea but could you give an example what type of
cascading logic this would be?


To unsubscribe, e-mail:
For additional commands, email:

View raw message