Date: 2004-09-18T13:32:38
Editor: MichaelMcGrady <[EMAIL PROTECTED]>
Wiki: Apache Struts Wiki
Page: StrutsCatalogDispatchUtil
URL: http://wiki.apache.org/struts/StrutsCatalogDispatchUtil
no comment
Change Log:
------------------------------------------------------------------------------
@@ -1,6 +1,8 @@
##language:en
== Universal Button Utility for Struts ==
+(Critics please use Critics Corner at the end of this post. Thank you.)
+
There is a persistent problem of handling multiple buttons, and this is especially a
problem when the buttons are images. Struts has provided a solution for this with
DispatchAction and its progeny. There are various other solutions. I have provided
one at StrutsCatalogImageTagUtil. I have actually provided two solutions there. The
following solution is, I think, superior in every way. What it does is to merge the
best parts of StrutsCataglogImageTagUtil and DispatchAction.
This is a solution for Struts. If you want a solution independent of Struts, again,
please see StrutsCatalogImageTagUtil. The principle reason for this class is the
problem with <input type='image' name='whatever'> tags in HTML. Those tag send the
values in the name attribute as ''whatever.x=9'' and ''whatever.y=26''.
DispatchAction and its progeny provide a melange of solutions but no common way to
deal with ''<a href='whatever.do'>'', ''<input type='submit'>'', ''<input
type='image'>'', ''<input type='file'>'', or whatever. This class, DispatchUtil does
that. If you prefer to use a subclass, just provide the functionality in this class
in a class extending Action. Herbert Rabago came up with the idea of providing the
functionality in a utility class and I really like that idea. So, here we go, after a
caveat.
@@ -9,6 +11,8 @@
For those who have used MappedDispatchAction and LookupDispatchAction, this solution
will do everything that you are doing. You have to understand, however, which many
people seem to have a really, really, really hard time doing, that there is a
fundamental shift in how the logic in this class, DispatchUtil and its prior class
SimpleDispatchAction work. There are those who want to say the equivalent of "0 is
just another number, so there is no big change here". I cannot continue to try and
awake them from their dogmatic slumbers. Let me just say for the last time that the
change from mining, getting, obtaining, etc. the name from the name/value request
parameter pair is a significant change that makes DispatchUtil lighter, more flexible
and less coupled in every respect. People continue to argue and to insist that this
class won't work as coded when it is doing fine in actual sites.
+== Code ==
+
=== DispatchUtil ===
{{{
package com.crackwillow.struts.util.dispatch;
@@ -151,7 +155,7 @@
}
}}}
-=== Some Explanation for Mapping and Lookup Dispatch Action Users ===
+== Discussion ==
All this means for you MappingDispatchAction and LookupDispatchAction users is that
where you used some value for the method in your action-mapping such as update, you
now have to use update.dispatch. If you override the method getMethodName( . . . )
and, instead of ''methodName =
paramProperty.substring(0,paramProperty.indexOf('.'));'' use ''methodName =
paramProperty'', you won't have to make any changes. If you want to avoid the use of
struts-config.xml altogether, you can. DispatchUtil really replaces not only
MappingDispatchAction, LookupDispatchAction and DispatchAction but also the necessity
those classes occasioned of using the parameter property of ActionMapping.
@@ -162,9 +166,13 @@
=== Links ===
StrutsCatalogMultipleImageTagsSimplified
+
StrutsCatalogInstrumentableForms
+
StrutsCatalogSimpleDispatchAction
+
StrutsCatalogHidingImagesAndOtherResourcesUnderWEBINF
+
StrutsCatalogMappedBeans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
