Re: DispatchAction

[Michael McGrady]

Steve Raeburn wrote:
Quick comments on your suggestion. Please don't mistake the brevity for
abruptness - just lack of time on my part.
 

I don't.  I appreciate all this "feedback" and discussion.  I like the 
idea of ideas being honed and forged with discussion and criticism.  It 
is a good thing and I know we all have limited time.

3. The example code doesn't work for SimpleDispatchAction. You are not
passing the ActionMapping parameter to the getMethodName method, which
requires it. Could you update the wiki with the correct code?
 

You are wrong about this.  The code presently is running and working 
fine on my application.  I know why you think this, but your conclusion 
is based on the same misconception everyone else has had when they first 
see SimpleDispatchAction.  It does not work the way they think.  This 
uses a really unusual twist which results in some surprising and not 
immediately understandable logic.

If you're proposing this as an additional action that *some* people might
find useful, then that's great. But I think you were suggesting this as a
*replacement* for DispatchAction/LookupDispatchAction/MappingDispatchAction,
but it simply does not do what those actions already do and so could not
replace them. 

This is, I think, false.  I think maybe you don't see what 
SimpleDispatchAction does, Martin.  Members on the user list have 
adapted it, in fact, in place of all those actions.  We are not used to 
seeing what it means to look for a name in a name/value pair.  This is a 
fundamental change in what we do.  It has been there to do, of course, 
and so is not invented.  But, SimpleDispatchAction does it and the 
results are cool, I think.  Doing so allows really powerful things to 
happen and creates surprising flexibility.

1. Big reason for not including this as a standard action is the use of '.x'
to identify the method name to dispatch to. The .x suffix has a particular
meaning in HTML (i.e. Image Button) and it would be incorrect/misleading to
subvert it for other uses that have nothing to do with image buttons.
 

I agree in a sense with this, and I would not be surprised if someone 
wanted to use a different class for those cases where there is no ".x" 
just for this reason.  However, let me tell you how this all happened.  
First, I wanted to solve the problem of the ".x" case, which 
LookupDispatchAction does, I think, in a cool but ugly fashion.  I tried 
Button classes but they were too heavy.  They really bog down 
performance, actually.  Then I tried an inner Button class in the 
ActionForm, which is associated with ImageTagUtil for "historical" or 
"hysterical" reasons on the wiki StrutsCatalog.  This was better.  
Finally, I realized that the simple solution in ImageTagUtil was the 
best.  Just mind, retrieve, get the value with ".x" and be done with 
it.  So I did.  This leads to the usual series of choices in the Action 
and associated classes for various methods, e.g. as in CRUD, etc.  That 
too was surprisingly slow, if you did not want to hard code values in 
the if and else if choices.  And, the code really got hard to read if 
there were significant numbers of methods.  This was really flexible though.

Then, following some prompting by people on the lists with their 
problems, I began to seek a generic button solution.  That mean using 
".x" throughout for consistency, even if this was not required.  But, 
that led me to a further discover beyond the scope of this note, viz. 
that leaving the value of the ".x" name free for other uses created a 
whole new kind of logic I had not even considered before with all sorts 
of interesting possibilities.  Instead of getting one value from a 
name/value pair, I was getting two values which could be assciated or 
not.  There is more, but you get the picture.  I have a very interesting 
whole application dealing with images and buttons which will be on the 
table in the near or not too distant future with some surprising aspects 
which really aid development, I think.

Also, I would not be happy with inclusion in Struts because of
the non-standard use of HTML.
 

I am on record as being of the opinion that I think nothing like this 
should be included with Struts but should be provided as possible code 
in wikis, etc., so I agree.  I just thought that if you were going to 
have three classes where one would do, you might want that.  I am not 
sure why you think the HTML used is non-standard, however.  You mean the 
use of names like update.x?  The HTML is standard.  The protocol for the 
values of the request name/value pairs is just expanded to four rather 
than one option in the semantics, leading to the flexibility previously 
discussed.  IMHO that LookupDispatchAction actually distorts normal 
practice with less benefits.

Thanks again for all your thought put into this.  I appreciate it a 
great deal and have enjoyed your posts over the time I have been 
around.  That goes for the other people assisting in this aa well.

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