Differences between revisions 1 and 2
Revision 1 as of 2005-08-31 05:12:23
Size: 2366
Editor: DonBrown
Comment: Adding validation discussion
Revision 2 as of 2009-09-20 23:11:40
Size: 2366
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

For validation, I propose we abandon the built-in validation process of Struts 1.x as I think it caused more problems than it solved. If so, we need to tackle the following issues:

  1. When to validate
  2. How to validate
  3. Where the validation cycle takes place
  4. How to pass on errors
  5. If we are using POJO's as the form, we need to handle conversion errors

Possible solutions:

When to validate

Validate in the following cases

  1. An controller action has a single parameter defined, probably the form.
  2. Anytime there are validations defined in annotations

Case 1 means that Struts won't automatically create a form for someone. I think this is fine as it is gives the user more direct control of the process. While a form would still take two actions, the first wouldn't define a form to be passed in but rather create it in the action. The second, having a defined form, would have the form validated and the errors stored.

How to validate

I think it would be good to stick to commons validator, however, we should create simplified xdoclet tags for most cases that will transform into validator xml. By continuing to use validator xml, it allows those if they want to define forms in it and also is one less piece of code to write :)

Where the validation cycle takes place

We could have the action be responsible for the validation cycle. I think this would be more intuitive and, with better support for "action chaining" (see xwork chain result type), would allow the input stage to prepare the form. As Struts 1.x stands now, your "input" attribute points to a JSP not allowing you to easily prepare the input page without code in the ActionForm.

=== How to pass on validation and conversion errors === I see the validation and conversion being stored in the context and made available there. I'll need to look at webwork again to see how they handle this, but I know that is how they make available conversion errors. Saving conversion errors allows you to have access to original erronous values. If we followed WW2's form tags, among other features, they use a value stack for providing data, allowing them to place the conversion error map in the stack before the actual form, meaning values would be retrieved from the conversion map automatically.

StrutsTi/FormValidation (last edited 2009-09-20 23:11:40 by localhost)