cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject RE: [RT] Revisiting Woody's form definition
Date Tue, 29 Jul 2003 12:47:15 GMT

Comments below.... :)

Carsten Ziegeler dijo:
> 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.

If we are going to a complete separation of concerns.... The business
object has the obligation of validate what it gets. If we see it as a
"model" in MVC, then we can use cocoon for view or other framework. A
business object cannot relay the validation task to other components. (It
only reforce what is told below...)

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

This is a good idea, but we must use validateAge() into getAge(). See

This is what is not clear to me in a OO design. At the end the Age will be
validated twice at the view and at the model. :( But maybe this is the
price to pay if we go full OO oriented.

> So (in conjunction 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.

Hmm. I am not sure. On one side, the Business model must validate the
fields. I agree that the form also had some degree of validation... but
sometimes the validation is too complicated (thinking in terms of a form).
ie: validating against a database.

I know this is not the case you are trying to show, but we will need to
take care of when we ask the form for validation and when not. No matter
is we have a validateAge() function. Because validateAge() can also be a
function to validate the correct age of a person, not only the interval of
the value.

I am not telling you are wrong, but there is a very thin frontier that is
very dificult to define. This is a very interesting point to talk about
and we need to define it.

On the other side I prefer the approach of defining datatypes for forms.
This is more general and allow us to define once a validation rule for a
defined datatype in a form. As you wrote above the example of the "age"
can be easily handled in the form. Of course in a defined model
(application) we can define some rules. ie: The age must be between 0 and

The rule validation encapsulated in a datatype allow us to "use" it in any
form no matter if the form show a doctor, a patient, a client or a
contact. All this entities has someone in common a validation rule for
datatype called "age".

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

I dont think this type of validation can be delegated to a form. For me
this type of validation is a model issue, not a view issue.

Also, in the web manage transactions is a very resource consuming task
(memory). Think in an attack that create too many "transactions" and never
ends it. This is the problem I see. Maybe this can be also an environment
with too many users.

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

Too risky. We will need to create a "manager" that take care of that. If
we have more than 2 open transactions there is always a posibility to
changes the data just before Cocoon send the form to the user. This is why
the model must validate always what it gets.

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

I think the answer is at the flow controller level. Your ideas looks
great, but it start mixing model and view in some way. And I think this is
exactly what we are trying to avoid. :(

Thanks for the ideas, I know this is a very "hairy problem". :)
Many of us are trying to find the right way in this stuff and of course
all the comments are welcome :)

Best Regards,

Antonio Gallardo

View raw message