I can see that your schedule and my attempting to say too much are confusing things. Let me also clarify a couple things so we are clear what we each are saying. Then I will address the bigger issues.
The following class works fine:
public abstract class CrackWillowLookupDispatchAction extends DispatchAction {
public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { String methodName = ImageTagUtil.getName(request); return dispatchMethod(mapping, form, request, response, methodName); } }
The other issues about this action have nothing to do with what I have been talking about, I think.
<html:form name='lookupForm' method='get' action='lookup.do' type='com.crackwillow.struts.form.LookupForm'>
<input type='submit' name='add.x' value='add'>
<input type='submit' name='delete.x' value='delete'>
</html:form>
This requires nothing in struts-config.xml.
I. Clarifications
A. Code Inside ActionForm Topic
The code I use for determining which <input type='image'> button has
been pressed is this utility class and this utility class alone.
public class ImageTagUtil { public static String getName(HttpServletRequest request) { String command = null; String buttonValue = null; Enumeration enum = request.getParameterNames();
while(enum.hasMoreElements()) { buttonValue = (String)enum.nextElement(); if(buttonValue.endsWith(".x")) { command = buttonValue.substring(0,buttonValue.indexOf('.')); } } return command; } }
The code in the form (inner class buttons) is an improvement on other solutions where there are button classes used. I don't like those solutions, including mine, which I think is better than the usual. The usual solution ends up really heavy with loads of buttons populating the situation,whereas this solution (which I don't like, remember) uses one inner button and one only. But, I don't use this at all. I removed it from the wiki as too complicating.
B. Different Commands for Different Images
What my image is has nothing to do with what the name value is. The
name value is the command and is completely decoupled from the
image. Neither has anything to do with the other. You can change
the image to anything you want and you can change the command to
anything you want. This is clearly true with the html too. <input
type='image' src='whatever.gif' name='whatever'> clearly decouples
what the gif is and what the name attribute value is. I extend this
by providing a tag which will produce an image with says whatever
it's name is: 'WHATEVER.gif' will be a gif with "WHATEVER",
'Whatever.jpg' will be a jpeg with "Whatever". So, we can have
"OK.gif" with name='viewFoo' and "OK.gif" with name='updateFoo'. That is not a problem. If they later decide that they want
"Yahoo.gif" or "GO.jpg" instead of "OK.gif", all you have to do is
change it and nothing else changes at all.
II. Issues
A. LookupActionMapping
My solution does not say a thing about using or not using the idea of executing a method by something like LookupActionMapping. Rather it is wholly about how to mine the values from the HTML.
The following simple code, in my solution, can replace a hugely complex series of relations and code in LookupActionMapping which drive you crazy and make any connection with ActionMapping's parameter attribute unnecessary as well.
execute(execute(ActionMapping mapping, ActionForm form,HttpServletRequest request, HttpServletResponse response) { return dispatchMethod(mapping, form, request, response, ImageTagUtil.getName(request)); }
So, the LookupActionMapping requires you IN ORDER TO ACHIEVE THE SAME THING to give the parameter attribute a value in the action mapping of struts-config.xml whereas my solution is completely decoupled from that. The LookupDispatchAction requires you to implement keyMethodMap relating methods to both the JSP and the action mapping of struts-config.xml. The fact that LookupDispatchAction uses reflection is important, of course, but is completely irrelevant to the principal ideas that LookupDispatchAction is based on. Other ways of mining the value of the method to be used can equally subclass DispatchAction.
Michael McGrady
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]