cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] Revisiting Woody's form definition
Date Wed, 30 Jul 2003 10:05:11 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.

ah, but in this case you might be just refering to having an easy 
  way to have custom datatypes?

so I think it is more related to the datatype-catalogue Sylvain 
is proposing the to how the binding is working...
(and hence probably my confusion)

> I want simple form definitions where possible, so I want to define
> a field that's bound to a business object and via introspection

yet here I get the impression you want the widget to be wrapped 
around the existing business object instance?

(so I'm still a bit confused)

what woody form-definition tries to do is map a 'widget' to a 
<input> field on the HTML page on the one side and

while the <input> will harvest nothing more then STRINGS at the 
user input side the widget is aware of its datatype and possible 
needed convertors to produce a new business-object from 
translating the string.
(in fact: when re-reading this I'm coming to the conclusion the 
current binding implementation has a bug: the field-binding needs 
to clone() the business object while doing a loadToForm())

on the java API side of the widget you get to have an Object 
getValue() and a setValue(Object) where the object returned resp. 
passed is guaranteed to be resp. needs to be of the datatype 
indicated by what you declared in the form-definition

> 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 what you are adding to the show is that the datatype 
(basetype) setting of the widget should be possibly derived from 
the binding path into the business object?

Sylvain is in the process of allowing to mix the different 
namespaces and concerns into a different set of config files, 
maybe his proposal can include something along these lines...

The rules for what is taking precedence over what should be 
carefully decided upon.

Just some additional remarks:

- the current binding works (through jxpath) by introspection of 
a handed over object-instance...

now (currently) the form-model building happens before the 
business object is there, so it will need to be done based on the 
actual class-files (adding the classname of your objectmodel to 
the ).  Given the fact that jxpath also maps paths onto keys in 
hashmaps the usage of this design-time approach is likely to 
limit the possibilities of using the binding across structures 
like this.

- the related remark on business-object-controlled validation is 
still lingering on the table... if I understood your 
validateAge() need then the configuration of the model would also 
need to allow to specify a validation method?  I guess in that 
case the woody framework will be imposing bahaviour on that 
method (return-type or exceptions to throw) which can't be met by 
existing models in the general case... so here I really think the 
accompanied custom validation rules will be better of in separate 
/specific classes.

> 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.

We are crossing the clear borders between the concerns we 
originally envisioned... I still think we got them right, but 
translating this into a 'usable' package clearly pushes us 
towards some careful mixing

let us try to make up the correct if/then rules to assume the 
best approach, and make sure we understand the limitations...

Careful documentation will need to ensure this doesn't become a 
mess IMHO

> 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 think we're saying the same, but unless we use the same words, 
we re bound to argue about the wrong things ;-)

> 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.
> 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.
> Does this make sense? 

it does... but as mentioned above I think we could reuse the 
form-manager and only need to reconsider the rules in the 
datatyping of things...

I'ld rather have us not branch up too early and start to live 
next to each other

thx for this clarification, I hope I returned the favour

more thoughts around?

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message