Date: 2004-08-11T07:00:35 Editor: MichaelMcGrady <[EMAIL PROTECTED]> Wiki: Apache Struts Wiki Page: StrutsCatalogMultipleImageButtonsWithNoJavaScript URL: http://wiki.apache.org/struts/StrutsCatalogMultipleImageButtonsWithNoJavaScript
no comment Change Log: ------------------------------------------------------------------------------ @@ -159,7 +159,7 @@ 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. +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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
