I have read most of the RT and think I have understand some parts of it. Now, I agree that keeping the field definitons as short and comprise as possible is good.
Now - without reading more of all the discussions and looking into woody - I just wanted to throw in some aspects which I think are currently not covered. Binding ------- I think the most important part is the binding to an existing business model (= java objects). I haven't looked at the current binding implementation and therefore can't say much about it. But my experiments showed that JXPaths is good but not good enough and I'm currently planning to improve JXPaths in some respects. The following notes are all tied to bindings: Datatypes --------- The explicit definition of datatypes in Woody is good, but I still think not needed if your form is bound to your strongly typed business model. For example if your field is bound to an int everything is said by this type (except any additional validation like range checks). So, I think the datatypes must be more optional and could be taken from the bound object model (if any). Validation ---------- It's good to have the possibility to define validation in the form and at the fields. But in some cases your business objects can validate their values as well and you don't want to code it twice. Simple Example: Imagine you have a user object with an age property modelled by an int. Now, it's only valid to set an age from 0 to 256. The business objects should check for valid values. One possibility could be by adding a validateAge(int) method to the user object, so it has three methods setAge, getAge and validateAge (where the last is optional). So (in conjunection with the binding) the validateAge method could be invoked to check if the value is valid. This allows validating values before they are set on the business objects. In case of an validation error the values should not be set using setAge() etc. Now, this is one idea I have. The other one deals with validation on complete business objects where perhaps one property depends on another. In this case, the form handling framework could start a "transaction". It first fetches all old values of the business objects, sets the new values and invokes the validation (validate() method on the business object?). When the validation is ok, the transaction is finished. If the validation fails, the transaction is rolled back and the old values are restored. These are only some thoughts, but for me the most important part is the binding and the interaction between the form handling and the business model. Carsten Sylvain Wallez wrote: > <snip great RT/>
