Hi, Rick,
WITHIN:
Rick Reumann wrote:
In the beginning of this application I assumed the client would always want to see all users so I created a MappingDispatchAction method (or regular DispatchAction method) called "getUsers(...)" which returned a list of all users in the company and put them in scope for the resulting page to display.
Imagine also that I had to put this link in a bunch of places within the web application.
Later on I'm told by the project manager that "we really need the client to be brought to a search criteria screen to filter out the number of users returned when trying to display users." I don't want to have to touch all the links in the application AND I also want to keep my "getUsers" dispatch method as is (maybe somewhere else I'll need it so I want to keep it around and not rename or alter it). What I need now because of the new requirments is a way to get to a search screen first when the user clicks on the 'Get Users" links.
For me this is very easy to change. I simply change the parameter in the struts-config for 'getUsers' to something like "setUpUserSearch" which would call that setUpUserSearch method and forward me to that search screen. (After submit I'd be brought to my search results).
Wouldn't you initial link in this scenario have looked something like:
<c:url var="url" value="/getUsers.do?getUsers.x=getUsers"/><a href="${url}">[ Get Users ]</a>
If so, wouldn't all of them need to altered if you wanted to go to 'setUpSearch' instead? (Remember I still want to keep getUsers method around for possible other parts of the application so I don't want to have to change that dispatch method behavior).
I want to stress that my solution will do everything yours does presently in this respect. If you want to do what you do with MappingDispatchAction, you can do that with the solution I suggest. I don't think there is anything your solution does that mine does not. I am rather sure of that. (Usually with "rather sure" I get the rude awakening. ;-) ) You don't have to use /getUsers.do?getUsers.x=getUsers but can use /getUsers.do simply with my solution and do exactly what you mention you would like to do, but which I think is a bad idea. I don't think it is a good idea, but my solution allows it, and does so with better performance and a cleaner logic, in my opinion. I just don't think this is a good idea, however. People looking at the page should get what they are "promised". Let me just expand, again, a bit on that.
Your solution will end up with getUsers.do on the page and an actual call to getSomeUsers in the mapping. If later you want to use your getUsers method, then you are going to have to create a getWhatever.do path and call getUsers in the mapping. I still think that this is a nightmare for creating potential problems. This is in addition to the fact that your solution requires you to create multiple mappings just to achieve this.
You can achieve what you want to do with MappingDispatchAction with SimpleDispatchAction not only by dooing what you do with MappingDispatchAction but also by using variables on the page. That makes more sense to me. I don't think you can do that with MappingDispatchAction. Let me look at that a bit.
I admit that this type of stuff won't happen that often. Your approach looking for .x is pretty cool. It's similar (I think:) to what I was planning on doing sort of with my MappingDispatchAction-combo where I over-rode the getMethodName method to something like...
protected String getMethodName(..) {
if( "dispatchMethod".equals( parameter ) { parameter = request.getParameter(parameter); } return parameter }
which would allow me to simply pass in a request parameter named dispatchMethod and this would override the use of the parameter name defined in the struts-config mapping corresponding to the method to call. For example...
<c:url var="url" value="/getUsers.do"> <c:param name="dispatchMethod" value="fooBar"/> </c:url> <a href="${url}">[ Get Users ]</a>
The above would act as your typical DispatchAction. (If I really go with this solution I wouldn't hard-code the "dispatchMethod" String)
This won't work for you. It will require you to change all the code grather than just the /getUsers.do. That, I think, is progress backwards, Rick. But, I do like the way you are searching for a generic solution. I am too. I am convinced that the way to go is either to change the /getUsers.do from
/users.do?getAllUsers.x=getAllUsers
to
/users.do?getSomeUsers.x=getSomeUsers
or to provide a variable for [getForBar.x=getFooBar].
DISADVANTAGES IN THE MappingDispatchAction
1. You are required to use multiple action mappings for methods.
ADVANTAGES IN THE MappingDIspatchAction
1. None, because everything you can do with the MappingDispatchAction can be done without it and the disadvantages.
DISADVANTAGES IN THE SimpleDispatchAction
1.. None,because there is nothing you can do with the MappingDispatchAction that cannot be done with the SimpleDispatchAction
ADVANTAGES IN THE SimpleDispatchAction
1. You can user either the url or the name/value pairs to pass the method name.
2. You can use this solution without using multiple action mappings.
3. You can use this solution with multiple action mappings and then use them with or without options in name/value pairs. (This gives you geometeric options.)
3. There is a significant performance difference in favor of the SmpleDispatchAction
4. There is a potential of using variables on the page which require no additional tags or coding.
So, you can see how objective I am, Rick. ;-)
Ok good night.. i'm way too tired:) Sorry if this was unclear.
You are very clear. Extremely clear. I think we are getting places. I acknowledge that my whole solution has been improve at least 100% by this discussion. While I did not like the DispatchAction reliance on the parameter attribute, I had let that blind me to the use of it as a reflection tool. I really think that what I am getting to now is really useful. It is fast too.
Good night.
Michael McGrady
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
