At 5:17 PM +0000 3/18/05, Lawrie Gallardo wrote:
I'm still relatively new to Struts, but I can't help but feel that validation would be better performed by Action classes rather than ActionForm classes.

It seems to me that, ideally, you want
1. Validation,
2. Transformations (ie convert separate day, month and year HTML fields to Java Date object), and
3. Mapping of ActionForm fields (/HTML parameters) to Domain POJOs / DTOs
to all be configured in the same config file (to minimise duplication) and to be implemented in the same class rather than scattered between multiple config files and classes.


Now, if my understanding is correct:
1. There is always a one-to-one mapping between an ActionForm and an ActionMapping,

Often not true. Earlier today on the dev-list Ted H. described a case where you might have a long form composed


2. Struts best practice is to have each Action class handle all possible operations for the HTML request it deals with using DispatchLookupAction or something similar,

I don't know if dispatch style is "best practice." It's my preferred approach, but many experienced Struts developers don't like it much at all. And then you've got wackos like Frank Z who like to write more code just to show off their typing skills.


3. Almost noone creates ActionForms manually any more - they use DynaActionForm (or validating variations of this).

Frank, again. ;-)

Now if this is the case, would it not be better to have the ActionForm as basically a dum data holder and have the validation method in the Action classes instead?

Sounds like WebWork. http://opensymphony.com/webwork/

Is it just down to design decisions made in early versions of Struts and backward compatibility that things are the way they are? Or are there good arguments for having the validation method in ActionForm? Am I missing something here?

The main reason you can't do it that way in Struts today is that Actions may service multiple threads and thus must remain stateless, while request data is inherently about state. WebWork, for example, instantiates its controller-type classes per-request, which makes it safe to populate them with request values and integrate request validation and control logic.


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]



Reply via email to