Thanks for your detailed answers, Joe.
Just a few queries though:
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
But isn't this subverting the ActionForm from its original design? I'll have to find that thread and read it before I say too much - but surely the whole point of an ActionForm is that it contains ALL the data from a submitted form?
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.
I'm relatively new to Struts and I have to say that I've found it to have a realtively steep learning curve. And the only reason for this is that there are so many different ways to do things and no definitive best ways of achieving anything. The phrase "Jack of all trades and master of none" springs (sic) to mind. I'd much rather there was a bit of focus to the framework than the mass of competing options. "Make the simple things simple and the hard things possible" and all that...
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/
My main motivation for learning Struts is that a lot of contracts are now specifying it as a requirement. Unfortunately, there doesn't seem to be anywhere near the same demand for WebWork, Spring MVC or Tapestry so it looks like I'm pretty much stuck with learning Struts.
If I didn't need to be pragmatic I would certainly be more than tempted to go with WebWork, Spring MVC or Tapestry (or a combination of them).
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.
Is object creation / garbage collection really that expensive any more? Is there any real reason for sticking with the current multithreaded one-Action-for-all-requests model rather than moving to an Action-per-request model. It seems to me that there should be a very good one in order to justify the coding style restrictions that the multithreaded model entails.
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 have to say that learning Struts has been a bit of a disheartening experience... There are frequently numerous ways of doing things, and often none of them seem ideal (and some appear to subvert the original design/architecture - the justification for which don't seem too coherent anymore). And whilst Struts offers a lot of functionality, and is very flexible, it just seems to me that there are a number of ways it could be improved upon / simplified that will never happen because it would break backwards-compatibility. I feel like it is going to take me weeks to work out the best way to do everything I need to be able to do (and whilst I'm doing this I'll have the thought at the back of my mind that I could be doing them much less painfully and efficiently with another framework...).
Lawrie.
From: Joe Germuska <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
To: "Lawrie Gallardo" <[EMAIL PROTECTED]>, user@struts.apache.org
Subject: Re: Wouldn't validation be better performed by Actions rather than ActionForms?
Date: Fri, 18 Mar 2005 11:42:18 -0600
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]
_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
