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.
yep.
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
<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 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?
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
