"Sobkowski, Andrej" wrote: > What if the > validation on the same bean is different depending on the app context? It > wouldn't be "clean" (for lack of better word) to consider both validations > inside the bean itself (validate())... hence the advantage of having > separate validation processes on the same bean (related to different app > contexts i.e. different actions). Am I missing the point?
That would be part of a second-level validation, along with "does a password and username match?". A first level validation would be whether a username and password were given, and whether confirmation passwords match each other. This is best handled by the ActionForm directly. > In the current Struts version, the validate() on the FormBean is called by > the ActionServlet.performValidate(...) method, isn't it? The validation is > part of the whole process that is controlled by the ActionServlet - from a > "procedural" point of view - and the same applies if the validate() is in > the FormBean or in the Action (the call is simply made on different entities > but in the same place). Or not? The controller calls validate, but has no idea what happens inside. Just like an Action might call a business method, but know nothing about the business logic. > A salomonic suggestion :) we could have different levels of validators: > bean-related and action-related. The first ones will take care of > first-level validations that always apply to the bean; the second will be > context-specific and called only if the first validations passed. But by > separating the validation process (by taking it out of the bean itself), it > would be possible to dynamically associate a validation process (validator) > with a bean/action. It's my personal opinion that the Action should not be directly involved in validation. It should happen at the ActionForm level (for efficiency) and at the business level (for completeness). But the Action is just an adapter, and should not be part of this type of logic. If the Action invokes a business method, and that method indicates that the data should be returned with a message, then the Action should do that, but without actually knowing why. I do believe that it would be useful if the ActionForm validate method could call upon a validation library that the business object might also use. But marrying this to framework in any other way encourages the placement of actual business logic in the Action itself, which I would not recommend. We put some validation in the ActionForm for the sake of efficiency, but the real validation belongs to the business tier, which is not part of the Web framework. I would sincerely like to see more tools like the Capco mapper, or the bean utilities Bill Wallace suggested, to help with the conversion, transformation and validation of properties. But it's important we think in terms of validating data for any application, not just a Web application or a Web application built with Struts. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
