cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Revisiting Woody's form definition
Date Wed, 30 Jul 2003 08:58:49 GMT
Carsten Ziegeler wrote:

>Marc Portier wrote:
>>there is a sample now doing that, above statement leaves it 
>>unclear if you tried that or not
>No, not yet.
>>if I understand what you are saying, then you would want to have 
>>the form definition (structure, fields, datatypes and convertors) 
>>  deduced from the (runtime?) introspection of the business model?
>>I (currently) don't think such is possible,
>>my own thinking towards some of this was more in the direction of 
>>using something like xdoclet to deduce this information from the 
>>extra @javadoc-attribuation of the source code and use that to 
>>generate the required woody-definition files
>I don't want to deduce all from the business model only the datatypes.
>I want simple form definitions where possible, so I want to define
>a field that's bound to a business object and via introspection
>it should be possible to get the type of the bound data of the business
>object, like Date, int, Long, String etc.
>That's all. Of course it should still be possible to define the
>datatype and validation for the field.
>So, rephraising it: the form definition should still be the same
>as it is. But the datatype should be optional and if it is not
>set it's get from the binding.
>likely to even consider woody to be useful),
>>I'm open to suggestions to make it more usuable and widely 
>>applicable, but we should never expect it to do everything 
>>imaginable (meaning: you have your choice of flow-implementation 
>>to host that part of the logic?)
>I'm suggestion all of the above as I successfully wrote web applications
>this way several years ago and I still think this fits very well
>in Cocoon, flow etc.
>So, I admit that I haven't looked at the recent changes in woody,
>but I get the impression that too much is added directly to woody. It's
>only a feeling, I might be wrong. Let's not argue about that.
>I'm wondering if it's possible to create a "form manager" component that
>has the default behaviour as you describe, a more web-based approach
>for form handling.
>Then I could somehow extend this form manager, add the binding in the
>form manager and can do there all the additional stuff to connect to 
>a business model.
>Example I: when woody tries to get the datatype of a field a method in
>this manager is invoked usually reading it from the definition. Now
>I can override this and additionaly query the business  model.

This is exactly the purpose of my proposal to separate datatypes from 
field definition : it's not only useful to increase reuse (no need to 
copy/paste the datatype between fields), but also to have other kinds of 
datatype definitions, the one I'm currently focusing on (because of my 
project) being the simpleTypes defined in an XMLSchema. And once 
datatype sources are pluggable, having an implementation extracting 
JavaBean properties should be rather simple to do.

>Example II: when woody tries to validate a method is called that
>defaults to validate against the rules defined in the form. I can
>override it and additionaly validate against the business model.

This calls for binding-specific validators that know both the 
application model and the form model. I proposed to add XPath predicates 
to the binding for this purpose. E.g :

<wb:field id="foo-field" path="foo">
    <wb:assert test="java:validateFoo($currentBean, $currentField/value)">
    <wi:fail-message>Business model rejects value for 

The variables are predefined by the binding framework (this is at the 
random thought state) :
- $currentBean is the bean holding the current property ("foo").
- $currentField is the "foo-field" that is currently being bound.

The "test" expression would thus call the "validateFoo" method on the 
business object.

Thoughts ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message