Now my 1 cent worth:)...
(sorry if this is wordy but I do wish some of you comment on it.. esp Martin and Niall because I'd be interested in your approaches)..
First off, I've used all the flavors of DispatchAction available so I'm familiar with their use. I'm certainly anti LookupDispatchAction ( could give plenty of reasons why but that's not the topic of this). At the moment I'm not bigoted one way or the other 'yet:)' towards use of the regular Dispatch, MappingDispatch, or Michael's SimpleDispatch.
Some thoughts first. One of the benefits in using Struts is that in the end it reduces the time it takes to develop a web application and makes it easy to maintain. The main reason I like the use of a DispatchAction is in regard to situations where you have multiple buttons on a form.
*Without using Javascript to swap out the form Action name, I'm curious how you guys accomplish using multiple buttons for a form without the use of a DispatchAction?* I know Martin and Niall said they don't like the DispatchAction so I am particularly interested in their approach to this. If I could solve that problem cleanly I might consider going back to separate regular Action classes to handle things - (EmployeeUpdateAction, EmployeeSetUpAction, EmployeeDeleteAction, etc). ( We could also debate whether a DispatchAction organizes things better - all CRUD in one related class - which I'd actually argue that a DispatchAction really does NOT help that much.... does save some typing, especially in regard to the Struts config.. but that's not too big a deal imo). Separate Actions would be fine for me if I could figure out the multiple button issue.
For example maybe a user form with two buttons "Update" and "Delete" which will either update the user information displayed or delete the user you are looking at. I'm curious how you would tackle this? You could of course submit to one regular Action that will look at the parameters but then you end up doing what a DispatchAction does. You could use Javascript to swap out the action name for the form (not a bad approach really. I was doing this). (Probably this example above is bad because in reality to do the delete all you would need is the delete button have an onClick that goes to a different Action passing in the user id and not really submit the form, but there are plenty of real life cases that do come up where you need the form submitted and do different things bases on what submit button was clicked).
What I do like about the SimpleDispatchAction is it does make things 'simple' you have one consistent way to handle all scenarios.
The main benefit I find in the use of the SimpleDispatchAction is that it handles the problem of multiple buttons or images on a form without having to use javascript to set a hidden dispatch parameter (or without having to use javascript to change a form action name if using MappingDispatchAction). What is nice is that the approach you use with these buttons is the same one used for links (pass in a name like update.x) (Using LookupDispatchAction with links is just very ugly).
In reference to the security issues of passing in exposed names of non-trivial Java methods in URLs, I agree this is a problem. But don't you run into the same problem using regular Actions? Your Action name itself if going to give a way what you are trying to accomplish (ie /udpateEmployee.do)
Martin Cooper wrote the following on 9/16/2004 10:59 PM:
I guess this thread has come to the point where I just have to throw in my 2 cents worth... ;-)
IMHO, dispatch actions, whatever flavour, are a bad idea in the first place. They are essentially second-level controllers. What for? You already have a perfectly good controller in the Struts ActionServlet, so why have your own additional levels of controller below that? It only complicates the mechanism by which an incoming request is handed off to the relevant body of code, and confuses people trying to understand how the application works.
As for which of SimpleDA, MappingDA, FubarDA, whatever, is the best, all I have to say is that exposing the names of non-trivial Java methods in URLs, and so visible outside the container, makes me very queasy from a security perspective. So if I was forced to use a dispatch action, I would certainly choose one that did not rely on a query string parameter to specify the method name.
-- Martin Cooper
On Thu, 16 Sep 2004 17:54:03 -0700, Michael McGrady <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
You're making the assumption that everyone wants to do things the way you do - SimpleDispatchAction doesn't replace any of them if people don't. Personally (if I used them :-)) MappingDispatchAction looks good to me for most use cases or if I didn't want to specify anything in the struts-config.xml then have a custom DispatchAction that just always used "method" as the parameter name to find the method name from the request.
Niall
I guess I am not communicating well at all.
I have no idea what people want to do and not only am I aware that people are not very predictable but also that I have no desire to try to get people to do anything whatsoever. I can tell you that also having been a Federal Public Defender I am really, really aware of the variety of choices people will make. ;-)
I just am saying that for my money a class that does exactly the same thing as three other classes and is faster, lighter, and less coupled is preferrable to me. I also suspect it will be preferrable to others, if that is right. So, I assumed the only issue was whether it was better, and not whether people liked things that were not better.
I would give people the dignity of arguing with them a bit about it, if they disagree, in order to see what they are thinking. I am not sure, Niall, that you see what is happening in this case, given you previous posts, but let me say that the logic in SimpleDispatchClass replaces the logic in all these other cases and gives you more flexibility. If you prefer to have to code the struts-config.xml when you don't have to and if you prefer to have heavier code in an underlying super class, and if you prefer to have a situation where you cannot use a single solution to all uses of buttons, then you won't want to use SmpleDispatchAction. But, if you do like your code to be simple, lightweight, generic, and fairly straightforward, you might try SmpleDispatchAction.
Do you see that you can do exactly the same thing with SimpleDispatchAction as with MappingDispatchAction and without the heavy load of DispatchAction? Do you see also that you can do exactly the same thing with SimpleDispatchAction as all three of these classes? Heck, if you see all this and prefer to use those classes, I would be surprised but would not be plussed. (Is there a "plussed" to go with "nonplussed"?)
The preceding sardonic presentation is meant to be a bit comical, but I would be interested, Niall, in knowing why you would do what you say you would, given what seems to be a pretty decided inferiority of the classes you say you would use. I may well be completely wrong in my assessment and would welcome any critique you have to offer. Maybe I too should do what you suggest, but I cannot see it.
Laughin' and Lovin' inWashington,
Michael McGrady
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Rick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
