However, even sticking to the current multithreaded Action model, why would this cause problems with validation? The ActionForm is currently passed by the ActionServlet as a parameter to the Action's execute() method - surely the ActionServlet could similarly pass the ActionFrom as a parameter to a validate() method on an Action object?
I was thinking you were still talking about the model where the Action and the ActionForm merged. Maybe I misunderstood you earlier. But what does it gain to move the validation inside the action?
I wasn't really thinking of merging ActionForm and Action - my motivation was the centralising of all validation, transformations (ie convert separate day, month and year HTML fields to Java Date object), and mappings (ActionForm / HTML parameters to Domain POJOs / DTOs) in just one place instead of these being split between ActionForm and Action classes. Plus it just seems odd to me to that:
1. You can have declarative validation occur through an invocation of the DynaValidatorForm class's validate() method but you need to manually create your own ValidatorActionForm if you need more complex (but still presentation-tier) validation. If instead declarative validation was invoked by the ActionServlet/RequestDispatcher through the Action's validate method then you could simply add any additional validation that there that could not be handled declaratively.
I see your point. This is why it's good to have fresh blood. Theoretically, you could write your own custom validators to plug-in to commons-validator, although even then, there are cases which are likely to elude it.
Don't forget that you can extend DynaValidatorForm and still defer all the easy stuff to declarative validation -- doesn't address your point directly, of course.
We once had a job to write to a client's homegrown MVC model which implemented things the way you describe, wherein their controllers had a validate method and then a perform method.
To be honest, it's rare enough that I have such complicated validation needs that it's hard for me to get too fired up about a change like this, especially considering potential compatibility implications. (not what you want to hear, I know...) So of course, my fallback then is to ask "can you at least do it yourself outside of the framework?" It would be extremely easy to write an abstract base action which called this.validate(mapping,form,req,resp) before calling this.execute(m,f,r,r). It's less clear how you would deal with actually instructing it that validation was required without somehow disabling the stage in which the request processor calls form.validate() instead. Or maybe you simply wouldn't need to do this -- just use the Action.validate form when you know you need it and only tend to the stuff which you know is more than the ActionForm can do.
2. If you have any complicated data transformation/mapping from HTML form fields to the type required by the business object, then the existing scheme would require the ActionForm to have knowledge of the business object(s) which seems wrong for a simple data holder / transfer object. Isn't an ActionForm supposed to just be a representation of the HTML request parameters in Java. If not, it suddenly becomes much less clear what it is actually supposed to represent.
Somewhat as before, the complexities in my apps usually don't lie in the form input, so this is a problem to which I haven't given much thought. As Hubert noted, his FormDef plugin sounds like it addresses some of your concerns. I think if a few more people gave that a try and started endorsing it, it would be a good candidate for inclusion in the core. I'll admit I've never tried it, but it sounds like a good general solution to a common problem. It's big enough that even though Hubert now has the power to just plug it in to Struts, it would still be good if a few more folks kicked it around and spoke up here about its strengths and weaknesses.
Again, this may be a philosophical difference, but I'm personally not that interested in having Struts solve every problem, especially if the community is willing to develop plugins that help solve common Struts problems without weighing down the core. From some of what you've said, I think you might prefer one-stop shopping, but I think lighter is better in the long-term.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
