Hi:
This is a nice discussion. Comments below....
This seems like mixing concerns. Model (validation) in with controller.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.
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
