Date: 2004-09-21T15:33:24 Editor: MichaelMcGrady <[EMAIL PROTECTED]> Wiki: Apache Struts Wiki Page: StrutsCatalogMultipleImageButtonsWithNoJavaScript URL: http://wiki.apache.org/struts/StrutsCatalogMultipleImageButtonsWithNoJavaScript
1092259842 Change Log: ------------------------------------------------------------------------------ @@ -67,9 +67,9 @@ 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. +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 this solution. A vastly inferior, I think, but more typical solution follows. +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. @@ -157,7 +157,11 @@ [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. +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. ---- @@ -241,3 +245,11 @@ 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
