cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: woody questions
Date Fri, 17 Oct 2003 07:57:59 GMT
Antonio Gallardo wrote:

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

Exactly. And especially when the flow is not static, i.e. when the page 
appearing when clicking "next" depends on what was input.

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

Yep.

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

Yep again. First rule of the web application writer: never, never trust 
the client. It's so easy to build a request. Never trust the values, and 
never trust the parameter names. XMLForm fell in this second trap by 
scanning the incoming request parameter names and considering them as 
XPath expressions on the data model. Woody on the other hand uses its 
server-side form model to define which request parameter to consider.

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

This is what I call "application-level validation", which correlate form 
values with other data out of range from the form. This can be e.g. 
checking that an ID actually exists in the database. The event listener 
stuff can do this to some extent, as a value-changed listener can call a 
application-defined validation code and set a validation error on the 
widget.

Note that in the particular case of the listbox, this is something that 
can be handled by Woody itself. Currently, selection-lists are just 
"hints" for the user, but no control is made that the incoming value is 
in this list. A useful feature should be to distinguish open and closed 
enumerations, i.e. if the list should be considered only as a help or as 
a list of allowed values. We can then render open enumerations as a 
combination of input+dropdown (combobox) and closed ones as what we have 
today.

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

Too much validation? I don't think so. It's just the way it should be, 
and what we sometimes fail to do simply because the available tools make 
it difficult.

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

Well, maybe it's language abuse: by "flow validation", you must 
understand "go back to the flow and from there call some 
application-specific validation code". The flow should be limited to 
glue code. It's a switchboard between the various components of the 
applications, and allows them to stay strongly decoupled.

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

I think we all agree on the principles ;-)

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message