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?
Sorry.. and I didn't even finish my thought.
Here's Ted's msg: http://article.gmane.org/gmane.comp.jakarta.struts.devel/26129
But there are two things; first, Ted's use case was for having the same form (and form bean) submit to different action paths (i.e. different action mappings). Also, a case where one ActionForm might not contain all the data would be if you were using a multi-page form/wizard type process, where each submission might carry only a subset of the overall data. Not everyone likes to use multipage forms, but Struts supports it.
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.
I wonder if there's an correlation between the many ways in which Struts can be done and the fact that it is popular in many environments. Pure speculation on my part.
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.
To be honest, I don't think so it is all that expensive, but until some mechanism comes up whereby Actions actually do get state from the framework, then there's no motivation to change the framework. Meanwhile, it is entirely possible to subclass the RequestProcessor and make Struts instantiate new Actions for each request. Spring's DelegatingRequestProcessor does exactly this.
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 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...).
That backwards compatibility is the reason you have so many people wanting you to know Struts to get their contracts. If Struts dropped backwards compatibility, they'd be no more interested in having you know a lot about the non-compatible Struts than they are in having you know about WebWork, Tapestry, or Spring MVC.
That said, Struts is under active development, and I feel like we have a lot of nice changes coming for Struts 1.3. A lot of them make things even more flexible, so maybe you'd disagree that they are nice changes. And these contracts that want you to know Struts may not be that interested in you knowing Struts 1.3 because it's new too. It will be some time before people believe our claims for backwards compatibility and endorse migration to the next version.
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]
