Re: DispatchAction

[Michael McGrady]

Hi, Niall,
Thanks for the discussion.  I have a few things to say on it which might 
be of interest.  I will be brief.

* It doesn't do EXACTLY the same as MappingDispatchAction or DispatchAction
(I'm ignoring LookupDispatchAction 'coz I don't like it). It almost does the
same as MappingDispatchAction except that MappingDispatchAction requires the
method name in the struts-config.xml and throws an Exception if it isn't
there. 

If you like doing this with MappingDispatchAction, then you can do it 
with SimpleDispatchAction as well.  It /is/ the same in this regard, 
Niall.  I am not sure why you think it isn't..  You don't /have /to do 
it but you can configure SimpleDispatchAction so that it will do exactly 
what MappingDispatchAction does in this regard.  I think it will in all 
regards.  I cannot imagine, given what I know of both classes, what 
would be an exception in this regard.

DispatchAction also throws an Exception if theres no parameter in
struts-config.xml and uses the parameter to find the name from the Request.
Can't see how you can say SimpleDispactgAction does exactly the same thing -
it doesn't.
 

The logic, of course, is different.  And, SimpleDispatchAction does 
things the others don't.  But, so far as I can see, if you want the 
behaviors of the other three, SimpleDispatchAction provides it.  I have 
not seen yet how it does not.

* I don't see how its "faster or lighter" - most of its code is just a
duplication of whats in DispatchAction and the only difference is the
determination of the method name.
 

Because of the way the value of the parameters are displayed, in 
LookupDispatchAction you have to have this whole initLookupMap code that 
is significant, I think.  In MappingDispatchAction you have to have all 
the code for the various paths.  You may want that.  And, if you do, it 
is available with SimpleDispatchAction, but it is not necessary and is 
heavier.  I might have overstated how heavy, but my prejudice is to get 
simple and light always.

* If I used dispatch actions I would create my own custom one that always
used "method" as the parameter name to get the method name from the Request.
I'm sure that would suit most situations, would mean nothing was required in
struts-config..xml and the custom action wouldn't have to go through all the
request parameters find one that ended in ".x"
 

You can do this, of course, but you would sacrifice a lot of flexibility 
in solving problems that I see people struggle with constantly on the 
list.  Indeed, SimpleDispatchAction was born recently out of an attempt 
to assist another engineer engaged in such a struggle.  I put a lot of 
stock in providing an easy architecture to the view team.  This solution 
gives them a simple solution and has no downside that I know of to date.

Well given that I don't use them its probably a bit rich stating my
"preferences" :-) but anyway. MappingDispatchAction looks OK to me - if I
hated specifying stuff in the struts-config.xml then I wouldn't be using
Struts. Also seems to me that having different "paths" for each of the
actions would be a good thing - my app controls user access based on the
path - so having /save.do and /delete.do with different parameters seems
like a better idea than just having one action mapping. Anyway I was never
argueing for this - but its different and I thinks its a valid option for
people to have.
 

It is one thing to "hate specifying stuff in the struts-config.xml file" 
but another to have to do so in order to meet certain problem domains.  
SimpleDispatchAction removes the necessity and takes away nothing that I 
know of to date.

I don't get the "heavy load" bit at all, not if you're taling about the
actual code in the classes rather than how you configure the xml and view to
use them.
 

The multiple mappings mean multiple classes, of course, vis-a-vis 
MappingDispatchAction.  And, the extra coding and the extra methods 
employed by LookupDispatchAction are what I call "heavy".

Actually never said I would use them - I don't, I use plain old Action
classes and am happy doing so.
 

Yah, they are not necessary.  I just determined what method to call by 
using a utility class to do what SimpleDispatchAction does not and then 
switches and the "if else if else if else if etc." in the past.  I have 
found out that using SimpleDispatchAction gives me much more speed.  I 
was amazed, actually.  The code is also a lot easier to read.  "public 
ActionForward update(....)" is a lot easier to follow in an action class 
than "else if(SiteConstant.UPDATE.equals(method))" for me.  So, I like 
the DispatchAction idea of using reflection.  I just hated the 
complexity and the inflexibility of the way the name of the method to be 
employed.  The biggest use for LookupDispatchAction is to get around the 
problem of there being an ".x" and a ".y" with <input type='image'>, 
after all.  I just tried to turn the problem into a plus.  And, so far, 
I think I have.

I am not trying to change your mind, but am, rather, trying to get a 
common ground whatever you want to do.  Some of the discussion is based, 
I think, on misinformation.

Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]