cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Revisiting Woody's form definition
Date Tue, 29 Jul 2003 11:58:08 GMT
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/>


Mime
View raw message