COLDThere were few solutions to buttons not long ago. So, this page should be an embassment of riches in some sense. I am going to talk straight on this page, so those with faint hearts and a desire to mince words to save souls should look elsewhere. This is business to me, not a club.
COLDFirst, let's talk about that labyrinth, the LookupDispatchAction in Struts. The actual process of coding and using this class is somewhat unsettling. If we forget that there were few good solutions to multiple images in forms until recently, we have to wonder "What were they thinking?". This is certainly a very clever solution. But, today, I think we should realize it is just off on all counts. It is too heavy, too convoluted, too coupled, just too many "too"s!
Forget for the moment what it takes to code this solution. Forget also for the moment that this solution conflates two very different issues, viz, using reflection to call a method and finding out what method is called. Take a look at what this solution requires to run. This is insanity in the present light of coding.
When a call is made to a use of this class, this is what happens when a "delete" is called which reads "Delete It" on the page.
The parameter attribute of the action mapping in struts-config.xml is called to get its value. Think of this. Why in the world would this be necessary? You won't believe why, if you have not studied this action.
The parameter attribute of the action mapping of the configuration file is used to get the value of whatever the page said, which in this case is "Delete It". You might, indeed, say "What?" and wonder why this happens. Let us suppose that the parameter attribute has as its value "method", which is typcial.
So, next, supposing the parameter attribute had as its value "method", we use this as a name in the request object name/value pairs to get the value of the request object parameter "method". Honest! I am not lying to you. What you will be surprised to learn is what the value of this is: it is "Delete It". Why do we want that value you might reasonably ask. The surprising answer is coming up after we create a reverse Map object of our ApplicationResource.properties file. Really, that is what we do.
A Map object which is a reverse directory of your ApplicationResources.properties file is now created so that we can get the key for the "Delete It" on the page, which came from the ApplicationResources.properties file. If you have a huge ApplicationResources.properties file, you obviously need to know this. Once we have this reverse directory, we can get the crucial key.
Now that you have the lookup map, you use it as follows. Since something like "button.delete" was used in the ApplicationResources.properties file to get "Delete It", e.g. a line in that file that read button.delete=Delete It, you can now use "Delete It" as a key in the reverse directory map and get "button.delete" as the value. Once again, I am not making this up.
Prior to using this Action, you had to code into your LookupDispatchAction subclass a hardcoded map. This map had key value pairs in it like: map.put("button.delete","delete"); Now, since we used the parameter attribute of the action mapping to get a name to get the value of the request object which held the name of the link on the page which once we created a reverse lookup map had the original name on the page (WHEW!), to use this original name ("button.delete") to get the value "delete". We now finally have the name of the method we want to call.
We now use "delete" in a call to some reflection code that calls a delete method. We are DONE! FINALLY!
Don't forget you had to code and to coordinate all of the labyrinth we just followed. Make a mistake in that tortured path, and things fall down. Imagine what this takes to maintain.
Let's turn to a simpler and better solution: the New DispatchAction class.
COOL!We can get the same result we just got by making the original name attribute (property attribute for Struts) be "delete.x" instead of "button.delete" and code a simple "for loop" to get the request parameter that ends in ".x". Honest. That is all our new DispatchAction does. Nothing else is required. No configuration. No coding the LookupDispatchAction map. No using the ApplicationResources.properties file. No creating a reverse lookup map. No using a reverse lookup map. And so on and so on and so on. This is what the new DispatchAction class does. I recommend it.
WAY COOL!Following the suggestion of Hubert Rabago, we can remove the code for the DispatchAction from the Action classes altogether. This was, I thought, an excellent idea, so we can use DispatchUtil to do exactly that.
HOT, BABY!We can complete decouple our solution from Struts by using the ImageTagUtil solution. Note that if you want to have reflection, you can still code that in your action and get the method lookup independently, as we do, from ImageTagUtil. Or, you can feed the results of this to the old DispatchAction class.
