cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT] Revisiting Woody's form definition
Date Wed, 30 Jul 2003 08:19:20 GMT
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.

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

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? 


View raw message