cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <>
Subject Re: woody questions
Date Fri, 17 Oct 2003 06:20:22 GMT

This is a nice discussion. Comments below....

>> > 3.  What about mutiple page forms?  Especially non-wizard (navigate
>> from any page to any page, etc.) forms?  I recall reading something
>> about handling multipage forms as separate forms tied together by a
>> flowscript controller?   However, are there not aspects of a form
>> (validation, business logic) which may span more than one page?  For
>>  example, how would one write a validation rule that says: { if user
>>  checks "reserve married housing" on page one, then their  answer to
>>  "single or married?" on page 3 must be "married"} ?
>> Woody only concentrates on a single form. The validation you explain
>> above can be done in the flowscript, by extracting the relevant values
>> from the forms to correlate them when all the needed values have been
>> input.
> This seems like mixing concerns.  Model (validation) in with controller.

Not at all. The controller must do the validations if we need to build a
"wizard-like" form. Who else can do that? I think woody is not a good
candidate for the job since it is just the "view". Who manage multiples
"views" the answer is the controller.

> My "gut feeling" is that validation rules should be in form (model)
> description markup. But maybe that's because I'm obsessed with client
> side validation. I need to think about this some more...

I think here are 3 levels of validations:

1. client-side (with javascript client-side)
Mainly to avoid a round trip to the server. This just saves user's time
while filling a form and nothing more.The server never can trust in this
type of validation of data. The user can "hack" the request and send you
any data inside.

2. Woody model (using woody validators)
You can not trust on the client-side validation. If we just support
client-side validation then there is a security concern. What if the users
just "hack the request". This is why woody must validate again what it
gets from the users.

3. Database (DDL - Data Definition Languaje)
Here again altrough Woody (or other form framework) can do his best effort
validating the user input, the database must also check what it get. i.e:
You send to the user a combobox or a listbox to choose some values from
there. Altrought the user again can "hack" to fool woody and the data
continue to the database. Here is the lastest point when we need to check
what we get.

I understand this is too much validation, but under this schema your
application will be more secure and realiable. Also note the parts can be
decoupled without problems.

While I am writing, I also tought about the flow validation (as pointed
above). I dont think flow is a good place to put validation in a database
application since it must do the work of a controller and nothing more.

What it means?

Flow just must "get" the request from the user and decide to whom (View or
Modell) it will send the request.

That is my point of view. I am currently working under this schema and I
hope it will work.

I just wanted to share this ideas under this interesting topic. Please
send your comments :-D

Best Regards,

Antonio Gallardo

View raw message