Personally I don't see how much we gain by writing custom validator unless the validation has to carried out in dozen of forms. Even in these cases it makes sense to have utility class/method and delegate the specific validation to this class.
2. When to use XML (validator plugin) and ActionForm validate() method.
The real advantage of validator plugin is it's capability to perform both - Server-side validation - Client-side validation. Particularly if your application needs to run on multiple browsers with straight forward client-side validation then validator saves you a lot of pain. Not everyone may agree with the point that we should try to restrict standard validator attributes provided in struts.
I prefer client-side validations to be simple check and server-side validation to be exhaustive. The ideal solution (as far as I can think) will be to
- Use validator plugin and define rules (primarily for client-side) - Let the action form extend ValidatorActionForm but override validate() method and call super.validate() to perform validations done on client-side to be carried on server-side and additional complex validations which is not easy to configure in validator plugin (without writing custom validator). - One overhead I can think of is if form is being used by multiple actions then validate() method will be big to cover each action unless it is modularized.
Honestly I haven't tested this approach but this is now my priority .
3. Between DynaActionForm and ActionForm? I haven't seen many applications really using DynaActionForm. My exposure to DynaActionForm is very limited.
Hope to see how other's look at these questions. [ October 31, 2006: Message edited by: Purushothaman Thambu ]
when should I use DynaActionForm over normal bean?
I personally don't like using DynaActionForm. With a good IDE, you can write a JavaBean that is a subclass of ActionForm just as quickly and easily as you can write the XML for the DynaActionForm properties. The thing I hate most about DynaActionForm is the way you retrieve properties.
I agree with Merrill on DynaActionForm. The syntax to get at the fields is just too ugly and error prone. Sure you don't have a bunch of form classes floating around but all you have done is move the code from Java into XML and made your struts-config file larger.
I actually put a fair amount of code into my action forms. I generally have code in there that knows how to populate the form from a DTO and how to populate a DTO from the form. I also treat my form as a "view helper" class so I might have a method like getFormattedName() that concatenates first, middle and last names. Generally if I can move logic or scriptlets out of a JSP an put them into the form I feel I am better off.