struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d..@struts.apache.org
Subject [Apache Struts Wiki] Updated: StrutsCatalogMultipleImageButtonsWithNoJavaScript
Date Thu, 12 Aug 2004 01:03:57 GMT
   Date: 2004-08-11T18:03:57
   Editor: MichaelMcGrady <michael@michaelmcgrady.com>
   Wiki: Apache Struts Wiki
   Page: StrutsCatalogMultipleImageButtonsWithNoJavaScript
   URL: http://wiki.apache.org/struts/StrutsCatalogMultipleImageButtonsWithNoJavaScript

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -1,255 +1,35 @@
-StrutsCatalog: '''Here are TWO WAYS to take care of that pesky and recurrent problem of how
to use multiple image buttons in your forms.  This solution will suggest other possibilities
you might want to code for yourself.  Use the one you like best.'''
+StrutsCatalog: '''This is an efficient way to end forever that pesky and recurrent problem
of how to use multiple image buttons in your forms.'''
 
-SOLUTION ONE: THE PREFERRED SOLUTION
 
-First, you can merely mine the parameterNames of the request and build your logic in your
processing of the request accordingly.  This is by far the best solution, in my opinion. 
It is simple and extensible.
+'''Assume that you have code not unlike:'''
 
 {{{
-public final class ButtonCommand {
-  private ButtonCommand() {
-  }
-
-  public final static String getCommand(HttpServletRequest request) {
-    Enumeration enum = request.getParameterNames();
-    String parameterName = null;
-    while(enum.hasMoreElements()) {
-      parameterName = (String)enum.nextElement();
-      if(parameterName.endsWith(".x")) {
-        return parameterName.substring(0,parameterName.indexOf('.'));
-      }
-    }
-    return parameterName;
-  }
-}
-}}}
-
-I use this with the following simple logic in a processing class called by my Action class.
 You can do whatever you like to use the results of the !ButtonCommand class.  You don't,
of course, have to have a Struts solution to use this.
-
-Assume that you have code like:
-
-{{{
-<input type='image' name='submit'>
-}}}
-
-Or:
-
-{{{
-<html:image property='submit'/>
-}}}
-
-or whatever else you may have going on.  Actually I automatically generate and cache buttons
of the right size, color, background, etc. on the fly in 15 languages as follows:
-
-{{{
-<crackwillow:image
-  button='HOSTS.gif'
-  mapBean='host_container'
-  bgClr='ffffff'
-  txtClrCode='banMddlBgClr'
-  font='Eurostile'
-  italic='false'
-  bold='true'
-  size='20'
-  property='hostsOptions'/>
-}}}
-
-But, none of this is related to the solution.  The solution is essentially unccnnected to
other issues.  The point is that the preceding solution is not tied to other decisions but
merely to utilizing what we need to get the job done with 
-{{{
-<input type='image>
-}}}
-
-We use the class as follows.
-
-{{{
-if ("submit".equals(ButtonCommand.getCommand(request))) {
-  // do whatever
-}
-}}}  
-
-Obviously the use is significant when we have more than one use of the image tags.  That
is the whole point.
-
-This solution is very, very simple and very, very effective.  I think it is the best out
there.  You can stop here.  But, if you are interested in sort of "legacy thinking", then
the following is "interesting" and, I think, an improvement on the normal way that button
classes are handled with image tags.
-
-Most importantly, there is very, very little overhead either in footprint or in calculations
with the previous solution.  A VASTLY inferior, I think, but more typical solution follows.
-
-SOLUTION TWO: THE TYPICAL BUT INFERIOR SOLUTION TYPE.
-
-Second, if you want something ostensibly more OOP in nature, then the following might be
your choice.  I have come to think the following is a mistake and but another instance of
overthinking a solution.  This second option is a bit better than some solutions, since it
has a small footprint comparatively.  But it is really a dinosaur in my opinion.
-
-The Struts page tags are simple.  If you have buttons you want called "submit" and "clear"
for example, you would have the following page tags:
-
-{{{
-  <html:image property='button.submit' src='Submit.gif'>
-  <html:image property='button.clear' src='Clear.gif'>
-}}}
-
-The resultant HTML producted by the magic html-image tag is:
-
-{{{
-  <input type=image name='button.submit' src='Submit.gif'>
-  <input type=image name='button.clear' src='Clear.gif'>
+<input type='image' name='update' src='change.gif'>
+<input type='image' name='delete' src='nuke.gif'>
 }}}
 
-PLEASE NOTE THAT THE name attribute in the HTML or the property attribute in the Struts html-image
tag is the name of the command or operation, not the "name" of the button.  The "name" of
the button, or "reference" of the button, is the src attribute.  Therefore, you could use
the following as well:
+'''or, in Struts' image tag:'''
 
 {{{
-  <html:image property='button.submit' src='CLICK.gif'>
-  <html:image property='button.clear' src='GO_BACK.gif'>
+<html:image property='submit' src='change.gif'/>
+<html:image property='delete' src='nuke.gif'/>
 }}}
 
-I used to just use a button and encorporated various Commands like Submit Clear, etc.  Discussions
with Larry Young of www.dalmatian.com convinced me that my solution was way to heavy-handed.
 Now, like the bloke who was turned into a newt but "got betta", my new and improved solution
is to provide a !ButtonForm to subclass or to copy, whatever excites you.  Here is the !ButtonForm
(if you want more buttons, just add to the getters, e.g. getSubmit():
+'''Now, how do we know which image has been clicked?  The answer has been complicated and
costly in the past.  Here is a simple way to achieve everything at a low cost and with great
flexibility and freedom.'''
 
 {{{
-public class ButtonForm
-    extends ActionForm {
-  protected CrackWillowButton button;
-  protected String command;
-
-  public CrackWillowButton getButton() {
-    if(button == null) { this.button = new CrackWillowButton(); }
-    return button;
-  }
-
-  public String getCommand() {
-    String hold = command; command = null;
-    return hold;
-  }
-
-  public void reset() {
-    button = null;
-  }
-
-  public class CrackWillowButton {
-    private Integer x, y;
-    public CrackWillowButton() { }
-    public CrackWillowButton getSubmit() { command = "submit";    return button; }
-    public CrackWillowButton getClear()  { command = "clear";    return button; }
-
-    public void setX(Integer x) {
-      if(y != null) { reset(); }
-      else          { this.x = x; }
-    }
-
-    public void setY(Integer y) {
-      if(x != null) { reset(); }
-      else          { this.y = y; }
+    String button = null;
+    Enumeration enum = request.getParameterNames();
+    String parameterName = null;
+    while(enum.hasMoreElements()) {
+      parameterName = (String)enum.nextElement();
+      if(parameterName.endsWith(".x")) {
+        button = parameterName.substring(0,parameterName.indexOf('.'));
+      }
     }
-  }
-} ///;-) 
 }}}
 
+'''There you go. Toss out the !LookupDispatchActions, the !ButtonCommands, etc.  This is
a done deal.  You can clearly seek other ways to ensure a bit more safety.  For example, the
code works equally as well with "submit.button" as it does with "submit".  Elegant, no, eh?
 
-Somewhere in the model, wherever we want to employ our logic, we check out which button type
has been pressed as follows:
-
-{{{
-  String command = buttonForm.getCommand();
-  if("submit".equals(command)) {
-    // do whatever
-  } else if ("clear".equals(command)) {
-    // do whatever
-  } else {
-    // some assert code
-  }
-}}}
-
-Enjoy!  And, thanks, Larry Young, for spurring me on to better ideas!  Namaste!
-
--- Michael !McGrady
-
-michael@michaelmcgrady.com
-
-N.B. The extension below conflates two differing ways of choosing what processing is required.
 If the image button is used to make this choice, then there is no need for a dispatch action.
 If you don't want to use the image to make this choice, that is fine.  But, using the two
together is a mistake, in my opinion.  The solution given below also uses the second solution
given here, which is by far the least prefered.  So, my suggestion is that you take the "extension"
below with more than a grain of salt.  The extension just complicates a simple solution.
-
-The point is this: if you use the LookupDispatchAction solution, you don't need this solution.
 If you use these solutions (either one), you don't need the LookupDispatchAction solution.
 Two solution in one is not better in this case.  The ".x" and ".y" in the parameter names
from an image tag operate very similarly to the parameter name for a !DispatchAction.  The
only difference is that they are built into the way the HTML works, rather than in the way
that the Struts specific !DispatchAction and LookupDispatchAction classes work.  
-
-Lastly, please note that the LookupDispatchAction does not take the solution away from the
execute method of the Action class.  Rather, it merely hides it in a super class.  Personally
I prefer to just call a process class in my Action classes within the execute method.  So,
for any XAction class, I have a XProcess class.  The point of this is merely to decouple the
Action and the business logic at the "get go".  I am not fond of the dispatch methodology
because it creates coupling rather than decoupling.  I am also not fond of the dispatch methodology
because it unnecessarily requires the configuration in the XML and unnecessarily uses the
parameter attribute, which can be used for something else if left alone.
-
-----
-
-Just an extension. 
-
-Instead of checking the command value in the execute method of the Action, you can make your
Action extend !DispatchAction by overriding the protected dispatchMethod
-
-{{{
-public class TestAction extends DispatchAction {
-       /**
-        * Dispatch to the specified method.
-        * @since Struts 1.1
-        */
-       protected ActionForward dispatchMethod(
-               ActionMapping mapping,
-               ActionForm form,
-               HttpServletRequest request,
-               HttpServletResponse response,
-               String name)
-               throws Exception {
-               return super.dispatchMethod(mapping, form, request, response, 
-                                          ((ButtonForm) form).getCommand());
-       }
-
-       public ActionForward submit(
-               ActionMapping mapping,
-               ActionForm form,
-               HttpServletRequest request,
-               HttpServletResponse response) {
-               return mapping.getInputForward();
-       } 
-
-       // Add more methods corresponding to the number of images (submits)
-}
-
-}}}
-'''OR''' by overriding the execute method
-{{{
-public class TestAction extends DispatchAction {
-       public ActionForward execute(
-               ActionMapping mapping,
-               ActionForm form,
-               HttpServletRequest request,
-               HttpServletResponse response)
-               throws Exception {
-
-               // Identify the request parameter containing the method name
-               String parameter = mapping.getParameter();
-               if (parameter == null) {
-                       String message =
-                               messages.getMessage("dispatch.handler", mapping.getPath());
-                       log.error(message);
-                       response.sendError(
-                               HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
-                               message);
-                       return (null);
-               }
-
-               // Identify the method name to be dispatched to.
-               // dispatchMethod() will call unspecified() if name is null
-               String name = ((ButtonForm) form).getCommand();
-
-               // Invoke the named method, and return the result
-               return dispatchMethod(mapping, form, request, response, name);
-       }
-
-       public ActionForward submit(
-               ActionMapping mapping,
-               ActionForm form,
-               HttpServletRequest request,
-               HttpServletResponse response) {
-               return mapping.getInputForward();
-       }
-       
-       // Add more methods corresponding to the number of images (submits)
-}
-
-}}}
-
-If we are dealing with too many images, then it's better to make it an !DispathAction similar
to the one illustrated above. One thing to remember is to define a parameter in the !ActionMapping.
-
-Thanks,
-Kishore Senji.
-
------
-
-Thanks, Kishore,
-
-If you use the first solution, there is no extra coding no matter how many images you use
for buttons.  You have to match what the property value is for <html:image> or the name
value for <input type='image'> and make sure that matches your logic in the model, but
that is all.  That, of course, has to be done with any possible solution.  This frees the
parameter attribute of your action mapping for other uses.  I, for one, have other very important
uses for this parameter attribute.  (I use it to allow a single mapping to go to multiple
layouts in tiles.)
-
-You also gain nothing from using the !LookupDispatchAction in this case.
+Michael !McGrady
+Cap't of the Eh Team'''

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message