> >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
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
implementations:
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?
regards
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
