Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by DonBrown: http://wiki.apache.org/struts/StrutsTi/FormValidation The comment on the change is: Adding validation discussion New page: #format wiki #language en 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 1. How to validate 1. Where the validation cycle takes place 1. How to pass on errors 1. 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. 1. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
