IMHO DispatchActions are more of a programmer convenience, than an additional level of controller. I don't use them to dynamically select the action at runtime (the job of the controller), just to let me organize code together and avoid duplication where the code seems to "belong" together. (e.g. CRUD operations).
In particular, with the MDA, the action is determined exclusively from the action path not from request parameters. Exactly the same as using standard, separate actions but - in some cases - more convenient. Steve -----Original Message----- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: September 16, 2004 7:59 PM To: Struts Developers List Subject: Re: DispatchAction 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
