At 4:45 PM +0200 18/7/01, Torsten Curdt wrote:
>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:
@Crudlet.org 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
>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.
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.
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.
regards Jeremy
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.
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
