Date: 2004-09-19T08:33:54
Editor: MichaelMcGrady <[EMAIL PROTECTED]>
Wiki: Apache Struts Wiki
Page: StrutsCatalogMultipleImageButtonsWithNoJavaScript
URL: http://wiki.apache.org/struts/StrutsCatalogMultipleImageButtonsWithNoJavaScript
1092229848
Change Log:
------------------------------------------------------------------------------
@@ -1,6 +1,8 @@
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.'''
-First, you can merely mine the parameterNames of the request and build your logic in
your processing of the request accordingly.
+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.
{{{
public final class ButtonCommand {
@@ -23,26 +25,55 @@
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:
+
{{{
-String command = ButtonCommand.getCommand(request);
-if (ButtonConstant.SUBMIT.equals(command)) {
- // do whatever
-}
+<input type='image' name='submit'>
}}}
-My !ButtonConstant class is equally simple. You might have, for example:
+Or:
{{{
-public final class ButtonConstant {
- public static final String CLEAR = "clear";
- public static final String DELETE = "delete";
- public static final String SUBMIT = "submit";
- private ButtonConstant() {
- }
-}
+<html:image property='submit'/>
}}}
-If you want something more OOP in nature, then the following might be your choice.
+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.
+
+Most importantly, there is very, very little overhead either in footprint or in
calculations with this 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:
@@ -107,7 +138,7 @@
}}}
-In the Action class, we check out which button type has been pressed as follows:
+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();
@@ -120,17 +151,19 @@
}
}}}
-Enjoy! And, thanks, Larry, for spurring me on to better ideas! Namaste!
+Enjoy! And, thanks, Larry Young, for spurring me on to better ideas! Namaste!
-- Michael !McGrady
[EMAIL PROTECTED]
+P.S. For my part, the suggested extension given below is just a further obfuscation
which has no value. All that it does is require us to add a layer for no apparent
benefit. Why do something that requires us to add XML values when that is totally
unnecessary? If I am missing something, my apologies. But, my philosophy is that a
solution does not need to be complicated. The extension also, of course, uses the
solution which is least desirable. Offhand, I can think of no reason not to use the
preferred solution. I have learned before, however, that sometimes I miss the best
ideas, and certainly encourage people to look at the following.
+
----
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
+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 {
@@ -204,7 +237,7 @@
}}}
-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.
+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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
