Re: DispatchAction security
Michael McGrady wrote: Mike Kienenberger wrote: Rick Reumann [EMAIL PROTECTED] wrote: Mike Kienenberger wrote the following on 9/17/2004 2:17 PM: Any time you allow an end user an opportunity to specify a parameter for reflection, you're introducing security concerns. However, a secure version could be created by only allowing a dispatch to a hardcoded list of methods. But your approach to encoding could do the same thing for a dispatch param so I'm not certain that using an Action vs DispatchAction is any more secure. I must not be understanding you. If you have url of /pagemethod=X and use reflection to resolve X, then you have far less control than if you simply check to see if X is in your list of approved methods. On the other hand, a pure action with /pageSaveButtonName=ButtonValue is always going to go to my save code if the SaveButtonName parameter exists, and it'll go to my default code if not. There's no other option. That's as secure as it gets. On the other hand, if you're just saying that you can encode your reflection dispatch name so that /pagemethod=X becomes /a1b2c3d4e5.psc, you've just made the security more obscure. If someone figures out your encoding, they can still bypass it. The first rule of computer security programming is never trust user data. Let users specify indexes of items in lists, never the item values themselves. I am not sure what you are saying, Mike. To bud in and sum up the other Mike's point, I think he was saying this: When you map request parameters directly to method names using reflection then the user can mangle the request parameters to set any property they want to... perhaps even unintended ones. Suddenly, any public properties are exposed to the world (or private ones if you've turned that on in security settings for some reason). -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction security
Mike Kienenberger wrote the following on 9/17/2004 7:13 PM: On the other hand, if you're just saying that you can encode your reflection dispatch name so that /pagemethod=X becomes /a1b2c3d4e5.psc, you've just made the security more obscure. If someone figures out your encoding, they can still bypass it. I still don't see how it becomes that much different. Take the two approaches (and correct me if I'm wrong, which I'm sure you will:): In approach one will assume going straight to a regular Action: /fooBar.do I'm assuming you'll have this encoded to look unintelligible to the user and it will end up resolving to use the /someAction.do mapping in your PageStateCacheServlet. In a dispatch approach you could have a URL that looked like /fooBar?dispatch=update I don't believe the above would be 'that' much more work to encode and decode? I don't think dispatch actions should be done away with because of security concerns. Those not using any kind of encoding stuff, like you are Mike, still often claim the regular Action is more secure because you don't have a dispatch parameter signifying what you are going. This argument is weak though because using a regular Action you can tell what you are doing just as easily. Couldn't most security concerns be checked when the user gets to the Action or by some filter? In other words, if someone mangles a URL to try to get to an update page when they should only be going to a view only page, you could always make sure to check the user has permission to get to that resource and kick them out if they don't. After reverting back to using regular Actions I decided to go back to using regular DispatchActions. I think they help organize the code better. Like I mentioned in another post, I don't see people breaking up a FooBarDao into UpdateFooBarDao, CreateFooBarDao, classes. I'm certainly not saying that using a Dispatch Action is that much better than breaking out the code into separate Actions, I'm just not seeing how the other side can claim the reverse though - That using regular Actions are much better. Possibly if it makes encoding much easier in some way, and that is an application requirement, than I could see how using regular Actions would be preferable in that instance. You could also always just code your DispatchActions with the unspecified method and then have the flexiblity to add other methods later if they logically fit within that class. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Steve Raeburn wrote 1. Big reason for not including this as a standard action is the use of '.x' to identify the method name to dispatch to. The .x suffix has a particular meaning in HTML (i.e. Image Button) and it would be incorrect/misleading to subvert it for other uses that have nothing to do with image buttons. Your critique gave me an idea, Steve. I think that I will avoid that .x stuff and just use something like: method.update in the HTML. The result will be the same and no one will get the willies over the .x. They also will see that the presence of .x is not what it seems to be. What do you think? Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
On Thu, 16 Sep 2004 21:19:03 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Martin Cooper wrote: IMHO, dispatch actions, whatever flavour, are a bad idea in the first place. They are essentially second-level controllers. What for? You already have a perfectly good controller in the Struts ActionServlet, so why have your own additional levels of controller below that? It only complicates the mechanism by which an incoming request is handed off to the relevant body of code, and confuses people trying to understand how the application works. The problem that dispatch actions are primarily related to, Martin, is determining which submit or image type was pressed when a form is submitted. This is condescending. I know what dispatch actions are for, and have done since before you knew they even existed. The problem is that you have to find out what the parameter is (it could be various things) and not what the value of a parameter is. The controller is not set up for this. The controller cannot do this. I agree that the usual way of doing this confuses people. Other ways, using Button classes in ActionForms, for example, which I have discussed at length elsewhere, is a really heavy and slow solution. I find SimpleDispatchAction or the associated ImageTagUtil, which does not use Action code at all clear and good ways to do this. You cannot avoid the problem. The problem is real. How do you solve it? JavaScript? Given the available solutions I have seen in Struts, which are: LookupDispatchAction, Button classes outside the ActionForm, Button class as an inner class in the ActionForm, ImageTagUtil, and SimpleDispatchAction, I vastly prefer the last two. That's why I coded them, of course, so I am prejudiced. As for which of SimpleDA, MappingDA, FubarDA, whatever, is the best, all I have to say is that exposing the names of non-trivial Java methods in URLs, and so visible outside the container, makes me very queasy from a security perspective. So if I was forced to use a dispatch action, I would certainly choose one that did not rely on a query string parameter to specify the method name. I am not sure what exposed methods you are talking about. This is not required at all. Thanks for you contribution to this. I am glad you weighed in. It is impossible to tell what silent people think. If you don't know what exposed methods I'm talking about, how could you possibly know that This is not required at all? You know very well what methods I'm talking about, and nowhere did I suggest that that they were required, only that they are extremely undesirable. -- Martin Cooper Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Steve Raeburn wrote: Michael, If that was you, Steve, trying to reach me on the chat, you caught me in the middle of changing based on your recommendation or objections from .x to method. The chat is now working. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Martin Cooper wrote: On Thu, 16 Sep 2004 21:19:03 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Martin Cooper wrote: IMHO, dispatch actions, whatever flavour, are a bad idea in the first place. They are essentially second-level controllers. The problem that dispatch actions are primarily related to, Martin, is determining which submit or image type was pressed when a form is submitted. This is condescending. I know what dispatch actions are for, and have done since before you knew they even existed. Well, when you call them essentially second-level controllers, Martin, I assumed you did not see they were essentially methods to get around the problem of not knowing which image with input type='image'. I don't know how to talk to you if you want to say they are one thing and get testy if I point out they are another thing. I am not sure what exposed methods you are talking about. This is not required at all. Thanks for you contribution to this. I am glad you weighed in. It is impossible to tell what silent people think. If you don't know what exposed methods I'm talking about, how could you possibly know that This is not required at all? You know very well what methods I'm talking about, and nowhere did I suggest that that they were required, only that they are extremely undesirable. Isn't the logic the other way around? I.e., if I DID know what exposed methods you were talking about then I could not know that This is not required at all? The truth is that I don't know what exposed methods you are talking about and so far as I can see such exposure is not required at all. Why this makes you so upset is a mystery to me. I am merely trying to state what I think here. I have no emotional commitment to this situation. I am not going to watch every word I say because you might read them to have hidden meanings or unkind intents I don't have, Martin. I hope you see that my statements were without any untoward view toward you or your abilities or anything else than the code. I think people have clearly misunderstood this class in many respects and they can expect me to say so. If I am wrong, then they can tell me. But I am interested in principles here, not personalities. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Now my 1 cent worth:)... (sorry if this is wordy but I do wish some of you comment on it.. esp Martin and Niall because I'd be interested in your approaches).. First off, I've used all the flavors of DispatchAction available so I'm familiar with their use. I'm certainly anti LookupDispatchAction ( could give plenty of reasons why but that's not the topic of this). At the moment I'm not bigoted one way or the other 'yet:)' towards use of the regular Dispatch, MappingDispatch, or Michael's SimpleDispatch. Some thoughts first. One of the benefits in using Struts is that in the end it reduces the time it takes to develop a web application and makes it easy to maintain. The main reason I like the use of a DispatchAction is in regard to situations where you have multiple buttons on a form. *Without using Javascript to swap out the form Action name, I'm curious how you guys accomplish using multiple buttons for a form without the use of a DispatchAction?* I know Martin and Niall said they don't like the DispatchAction so I am particularly interested in their approach to this. If I could solve that problem cleanly I might consider going back to separate regular Action classes to handle things - (EmployeeUpdateAction, EmployeeSetUpAction, EmployeeDeleteAction, etc). ( We could also debate whether a DispatchAction organizes things better - all CRUD in one related class - which I'd actually argue that a DispatchAction really does NOT help that much does save some typing, especially in regard to the Struts config.. but that's not too big a deal imo). Separate Actions would be fine for me if I could figure out the multiple button issue. For example maybe a user form with two buttons Update and Delete which will either update the user information displayed or delete the user you are looking at. I'm curious how you would tackle this? You could of course submit to one regular Action that will look at the parameters but then you end up doing what a DispatchAction does. You could use Javascript to swap out the action name for the form (not a bad approach really. I was doing this). (Probably this example above is bad because in reality to do the delete all you would need is the delete button have an onClick that goes to a different Action passing in the user id and not really submit the form, but there are plenty of real life cases that do come up where you need the form submitted and do different things bases on what submit button was clicked). What I do like about the SimpleDispatchAction is it does make things 'simple' you have one consistent way to handle all scenarios. The main benefit I find in the use of the SimpleDispatchAction is that it handles the problem of multiple buttons or images on a form without having to use javascript to set a hidden dispatch parameter (or without having to use javascript to change a form action name if using MappingDispatchAction). What is nice is that the approach you use with these buttons is the same one used for links (pass in a name like update.x) (Using LookupDispatchAction with links is just very ugly). In reference to the security issues of passing in exposed names of non-trivial Java methods in URLs, I agree this is a problem. But don't you run into the same problem using regular Actions? Your Action name itself if going to give a way what you are trying to accomplish (ie /udpateEmployee.do) Martin Cooper wrote the following on 9/16/2004 10:59 PM: I guess this thread has come to the point where I just have to throw in my 2 cents worth... ;-) IMHO, dispatch actions, whatever flavour, are a bad idea in the first place. They are essentially second-level controllers. What for? You already have a perfectly good controller in the Struts ActionServlet, so why have your own additional levels of controller below that? It only complicates the mechanism by which an incoming request is handed off to the relevant body of code, and confuses people trying to understand how the application works. As for which of SimpleDA, MappingDA, FubarDA, whatever, is the best, all I have to say is that exposing the names of non-trivial Java methods in URLs, and so visible outside the container, makes me very queasy from a security perspective. So if I was forced to use a dispatch action, I would certainly choose one that did not rely on a query string parameter to specify the method name. -- Martin Cooper On Thu, 16 Sep 2004 17:54:03 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Niall Pemberton wrote: You're making the assumption that everyone wants to do things the way you do - SimpleDispatchAction doesn't replace any of them if people don't. Personally (if I used them :-)) MappingDispatchAction looks good to me for most use cases or if I didn't want to specify anything in the struts-config.xml then have a custom DispatchAction that just always used method as the parameter name to find the method name from the request. Niall I guess I am not
Regular Action? Re: DispatchAction
Rick Reumann wrote the following on 9/17/2004 11:03 AM: The main reason I like the use of a DispatchAction is in regard to situations where you have multiple buttons on a form. You know, the more I think about I think I might just go back to using reular ActionForms and not even bother with any of the Dispatch types. For cases where I would have a few extra buttons that would behave differently, I could just check that parameter in the execute method. I know this ends up being a dispatch of sorts, but to me it won't be 'that' bad since 1) I usually don't have that many situations where there are a lot of extra buttons on a form and 2) So what if it acts like a dispatch action? It's only a few extra lines of code creating the if/else checks for the parameter name (Or I can do one check for that dispatch paramater name and if exists just execute that ActionDispatcher class that Niall created ). I'm still curious on other approaches concerning mutliple buttons that submit a form (that don't involve use of a Dispatch flavor). -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Rick Reumann [EMAIL PROTECTED] wrote: *Without using Javascript to swap out the form Action name, I'm curious how you guys accomplish using multiple buttons for a form without the use of a DispatchAction?* You could of course submit to one regular Action that will look at the parameters but then you end up doing what a DispatchAction does. This is the approach I decided on. Downsides are that they're somewhat hardcoded into each action. Upsides include better security and no base class multiple inheritance issues. You could use Javascript to swap out the action name for the form (not a bad approach really. I was doing this). Requires that your end users have javascript enabled. In my opinion, javascript should enhance an application if available, but not be a necessity. What I do like about the SimpleDispatchAction is it does make things 'simple' you have one consistent way to handle all scenarios. In reference to the security issues of passing in exposed names of non-trivial Java methods in URLs, I agree this is a problem. Yeah, and this is the reason why, although I like the simplicity of SimpleDispatchAction, I will probably never use it. Any time you allow an end user an opportunity to specify a parameter for reflection, you're introducing security concerns. However, a secure version could be created by only allowing a dispatch to a hardcoded list of methods. But don't you run into the same problem using regular Actions? Your Action name itself if going to give a way what you are trying to accomplish (ie /udpateEmployee.do) Not relevent to my situation. We require a WebObjects-like page state cache to handle backtracking issues. Thus our URLs end up looking like http://.com:/ebpp/duSRSod7x598ZkHOQ16p1spKaMzS3yj1Dj_1.1.psc and contain no user-meaningful information. This allowed me to get rid of two of the three struts security issues I identified when first using the technology: - all pages are random-access accessible - page-scope variables are passed back to the client between requests and are subject to alteration Downside is that you have to add your own bookmarking scheme (could be as simple as bookmark=x appended to the end) if you care about that. Other downside is that you have develop a page state servlet :) but that took less than a week. -Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regular Action? Re: DispatchAction
Sorry to clug the dev list with this, but since the topic started here, I'll continue. What about this approach that when enable the use of regular Actions and would handle the multiple button problem I like the concept of using single Actions since it isolates what you are doing in a single class (vs a method in a class). What I was thinking is in the cases where you needed to use multipe buttons on a form you could simple create an Action that would handle this request and call the appropriate Action. For example, you have yoru typical UserUpdateAction, UserDeleteAction etc., but then you might have a UserMultipleActionHandler that would call one of the above Actions based on a param. The benefit to this your regular Actions remain independent and can be used as normal. You'd only need the handler when you have multiple buttons submitting the form. Uggh the whole problem with all of this is it seems like I'm going backwards:) In other words, my first MVC app had one controller servlet and simple Command objects that would be called (which would return a foward param). When you think about it, that's all Actions really are (but with a handle to the Request/Response). Rick Reumann wrote the following on 9/17/2004 2:12 PM: Rick Reumann wrote the following on 9/17/2004 11:03 AM: The main reason I like the use of a DispatchAction is in regard to situations where you have multiple buttons on a form. You know, the more I think about I think I might just go back to using reular ActionForms and not even bother with any of the Dispatch types. For cases where I would have a few extra buttons that would behave differently, I could just check that parameter in the execute method. I know this ends up being a dispatch of sorts, but to me it won't be 'that' bad since 1) I usually don't have that many situations where there are a lot of extra buttons on a form and 2) So what if it acts like a dispatch action? It's only a few extra lines of code creating the if/else checks for the parameter name (Or I can do one check for that dispatch paramater name and if exists just execute that ActionDispatcher class that Niall created ). I'm still curious on other approaches concerning mutliple buttons that submit a form (that don't involve use of a Dispatch flavor). -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
Not relevent to my situation. We require a WebObjects-like page state cache
to handle backtracking issues. Thus our URLs end up looking like
http://.com:/ebpp/duSRSod7x598ZkHOQ16p1spKaMzS3yj1Dj_1.1.psc and
contain no user-meaningful information.
Wow I'd like to see how you implemented that some day. Sounds pretty
cool. So I take it your Struts JSP Form would look like...
html:form action=${updateSecure}
Where you'd pass to the page this encoded String for the action name and
then it gets translated somewhere in the RequestProcessor to equate to
an actual mapping in the struts-config?
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Martin Cooper wrote the following on 9/16/2004 10:59 PM: IMHO, dispatch actions, whatever flavour, are a bad idea in the first place. They are essentially second-level controllers. What for? I'm still not totally convinced DispatchActions don't have their place for handling CRUD stuff. Do you create separate DAO classes for each Database operation DaoUpdateEmployee, DaoDeleteEmployee? Usually you have a Dao that encapsulates those common operations related to an Employee - EmployeeDAO. I think of DispatchActions in a similar light. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction security
Rick Reumann [EMAIL PROTECTED] wrote: Mike Kienenberger wrote the following on 9/17/2004 2:17 PM: Any time you allow an end user an opportunity to specify a parameter for reflection, you're introducing security concerns. However, a secure version could be created by only allowing a dispatch to a hardcoded list of methods. But your approach to encoding could do the same thing for a dispatch param so I'm not certain that using an Action vs DispatchAction is any more secure. I must not be understanding you. If you have url of /pagemethod=X and use reflection to resolve X, then you have far less control than if you simply check to see if X is in your list of approved methods. On the other hand, a pure action with /pageSaveButtonName=ButtonValue is always going to go to my save code if the SaveButtonName parameter exists, and it'll go to my default code if not. There's no other option. That's as secure as it gets. On the other hand, if you're just saying that you can encode your reflection dispatch name so that /pagemethod=X becomes /a1b2c3d4e5.psc, you've just made the security more obscure. If someone figures out your encoding, they can still bypass it. The first rule of computer security programming is never trust user data. Let users specify indexes of items in lists, never the item values themselves. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction security
Mike Kienenberger wrote:
Rick Reumann [EMAIL PROTECTED] wrote:
Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
Any time you allow an end user an opportunity to specify a parameter for
reflection, you're introducing security concerns.
However, a secure version could be created by only allowing a dispatch
to
a hardcoded list of methods.
But your approach to encoding could do the same thing for a dispatch
param so I'm not certain that using an Action vs DispatchAction is any
more secure.
I must not be understanding you.
If you have url of /pagemethod=X and use reflection to resolve X, then
you have far less control than if you simply check to see if X is in your
list of approved methods.
On the other hand, a pure action with /pageSaveButtonName=ButtonValue is
always going to go to my save code if the SaveButtonName parameter exists,
and it'll go to my default code if not. There's no other option. That's
as secure as it gets.
On the other hand, if you're just saying that you can encode your reflection
dispatch name so that /pagemethod=X becomes /a1b2c3d4e5.psc, you've
just made the security more obscure. If someone figures out your encoding,
they can still bypass it.
The first rule of computer security programming is never trust user data.
Let users specify indexes of items in lists, never the item values
themselves.
I am not sure what you are saying, Mike. Suppose we have use the
following actions. One action has the following:
1. SOLUTION ONE
Action that Chooses What CRUD to Use from the Button
public ActionForward execute(...) {
String command = getCommandName();
if(save.equals(command)) {
save(request.getParameter(SaveButtonName));
} else if (delete).equals(command)) {
delete(request.getParameter(DeleteButtonName));
}
}
return mapping.getInput();
}
2. SOLUTION TWO: Dispatchers
Action that Chooses what CRUD Method to Call Via Reflection
public ActionForward execute(...) {
// Dispatch util is a method to get the methodName and use one of
the following methods by reflection
forward = new
DispatchUtil().dispatch(this,mapping,form,request,response);
}
public ActionForward save( ...) {
String ButtonValue = request.getParameter(SaveButtonName);
// use ButtonValue
}
public ActionForward delete( ... ) {
String ButtonValue = request.getParameter(DeleteButtonName)'
// use ButtonValue
}
}
3. SOLUTION THREE:
Plain Old Action Objects
SaveButtonAction
public ActionForward execute () {
String ButtonValue = request.getParameter(SaveButtonName);
/// do whatever
}
DeleteButtonAction
public ActionForward execute () {
String ButtonValue = request.getParameter(DeleteButtonName);
/// do whatever
}
Isn't the third option in fact the least safe? And, isn't the dispatch
option at least tied for the most safe? The safety of the parameter and
its value is in all three models, but in the plain old action object,
that is the only distance between a hack and the application, whereas
in the other cases there are added levels of security due to the
complexity of the internal logic. Ultimately the level of complexity
and the bottom security the name/value pair from a request parameter for
what must be deleted, etc. is the same in ALL cases. What is different
is that the object for deleting is an obvious target whereas the
operations are hidden in an object represening, in essence, an actor
rather than an action.
Please do not take this question as disingenuous or otherwise as an
attack on you. I don't even know you. This is just an attempt to
exchange ideas. I don't mean to suggest you would react that way but I
have gotton gun shy on this list. Thanks. I am interested in your answers.
Michael McGrady
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: DispatchAction (was: [Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction)
I was actually thinking of playing around with this idea, so that the
way the method is determined is refactored out, similar to how you
(Niall) changed ValidatorActionForm.
Specifically, I'm interested in figuring out if we can refactor it in
such a way that it becomes useful to other Action hierarchies. One of
the issues with using an app-specific base class is that they lose the
functionality provided by the Action subclasses that comes with
Struts. If we can move this code outside of the *DispatchAction
classes, app-specific base classes can take advantage of these
features as well.
Hubert
On Thu, 16 Sep 2004 18:05:46 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Date: 2004-09-16T11:05:45
Editor: NiallPemberton [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: StrutsCatalogSimpleDispatchAction
URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction
no comment
Change Log:
--
@@ -179,5 +179,47 @@
'''Michael !McGrady'''
+
+Seems to me that most of the SimpleDispatchAction duplicates whats already in the
DispatchAction class. If we re-factored DispatchAction so that the parameter
retrieval was moved into a new getParameter() method then all that would be needed
to achieve what you want is a flavour that overrides the
getParameter()/getMethodName() methods.
+
+Something along the lines of ...
+
+{{{
+public abstract class SimpleDispatchAction extends DispatchAction {
+
+ protected String getParameter(ActionMapping mapping,
+ActionForm form,
+HttpServletRequest request,
+HttpServletResponse response) {
+
+return mapping.getParameter();
+
+ }
+
+ protected String getMethodName(ActionMapping mapping,
+ ActionForm form,
+ HttpServletRequest request,
+ HttpServletResponse response,
+ String parameter) {
+
+if((parameter != null) (parameter.endsWith(.x))) {
+ methodName = parameter.substring(0,parameter.indexOf('.'));
+} else {
+ Enumeration enum = request.getParameterNames();
+ while(enum.hasMoreElements()) {
+buttonValue = (String)enum.nextElement();
+if(buttonValue.endsWith(.x)) {
+ methodName = buttonValue.substring(0,buttonValue.indexOf(.x));
+}
+ }
+}
+return methodName;
+ }
+
+}
+
+}}}
+
+'''Niall Pemberton'''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
What SimpleDispatchAction does not duplicate is the logic of
DispatchAction vis-a-vis the view in the MVC. There is no need at all
for a getParameter() method in SimpleDispatchAction. The logic if very
different. In essence, DispatchAction substitutes the parameter of
ActionMapping for the name in submit and adds the value of name to the
parameter in ActionMapping. SimpleDispatchAction avoids all of this by
strip mining the name in submit, image, file, link, etc. and leaving the
value in the request parameter and the value of the parameter in the
MappingAction to be whatever you want.
I think myself that some of these classes are just good ideas and really
should not be in the Struts application. If you start putting these in
you will just, I think, bloat Struts unnecessarily. If someone wants
these, they should be available on the wiki or whatever. However, if
you think they should go into the Struts application itself, then I
don't think the suggestion really works. You simply have way too much
baggage in DispatchAction for SimpleDispatchAction. If you wanted to
refactor by reversing the situation and making SimpleDispatchAction the
superclass, that, I think, works better. But the actual use of these
two classes is so radically different I actually think separating them
entirely would be the best bet. The only thing they have in comom is
the use of the reflection really. That is not much in common. They do
meet similar needs but in radically different ways.
Michael McGrady
Hubert Rabago wrote:
I was actually thinking of playing around with this idea, so that the
way the method is determined is refactored out, similar to how you
(Niall) changed ValidatorActionForm.
Specifically, I'm interested in figuring out if we can refactor it in
such a way that it becomes useful to other Action hierarchies. One of
the issues with using an app-specific base class is that they lose the
functionality provided by the Action subclasses that comes with
Struts. If we can move this code outside of the *DispatchAction
classes, app-specific base classes can take advantage of these
features as well.
Hubert
On Thu, 16 Sep 2004 18:05:46 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Date: 2004-09-16T11:05:45
Editor: NiallPemberton [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: StrutsCatalogSimpleDispatchAction
URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction
no comment
Change Log:
--
@@ -179,5 +179,47 @@
'''Michael !McGrady'''
+
+Seems to me that most of the SimpleDispatchAction duplicates whats already in the
DispatchAction class. If we re-factored DispatchAction so that the parameter retrieval
was moved into a new getParameter() method then all that would be needed to achieve
what you want is a flavour that overrides the getParameter()/getMethodName() methods.
+
+Something along the lines of ...
+
+{{{
+public abstract class SimpleDispatchAction extends DispatchAction {
+
+ protected String getParameter(ActionMapping mapping,
+ActionForm form,
+HttpServletRequest request,
+HttpServletResponse response) {
+
+return mapping.getParameter();
+
+ }
+
+ protected String getMethodName(ActionMapping mapping,
+ ActionForm form,
+ HttpServletRequest request,
+ HttpServletResponse response,
+ String parameter) {
+
+if((parameter != null) (parameter.endsWith(.x))) {
+ methodName = parameter.substring(0,parameter.indexOf('.'));
+} else {
+ Enumeration enum = request.getParameterNames();
+ while(enum.hasMoreElements()) {
+buttonValue = (String)enum.nextElement();
+if(buttonValue.endsWith(.x)) {
+ methodName = buttonValue.substring(0,buttonValue.indexOf(.x));
+}
+ }
+}
+return methodName;
+ }
+
+}
+
+}}}
+
+'''Niall Pemberton'''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
I don't see anything radically different in SimpleDispatchAction to the
other DispatchAction flavours - it just uses a slightly different mechanim
for determining the method name to execute and it doesn't throw an exception
if the parameter is null.
Looking at it, it seemed to me that factoring out retrieving the parameter
in DispatchAction into a separate method would mean that your
SimpleDispatchAction could re-use the bulk of the DispatchAction code that
it was duplicating and just provide the slight different flavour of method
name determination that you are keen on by overriding the getMethodName()
method - making SimpleDispatchAction much simpler :-)
Personally I don't use DispatchAction or any of its flavours at all and for
me SimpleDispatchAction doesn't seem to provide that much difference in
behaviour to make me think it would be worth adding into Struts - but if the
getParameter() refactoring of DispatchAction is helpful and makes extending
its behaviour easier then I'd be willing to do that.
To be honest Michael I'm confused by you saying SimpleDispatchAction is
*radically* different - I just don't see it. Maybe if you could point out
the radical differences in simple enough sentances for me understand then I
might get it?
Niall
- Original Message -
From: Michael McGrady [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Thursday, September 16, 2004 8:44 PM
Subject: Re: DispatchAction
What SimpleDispatchAction does not duplicate is the logic of
DispatchAction vis-a-vis the view in the MVC. There is no need at all
for a getParameter() method in SimpleDispatchAction. The logic if very
different. In essence, DispatchAction substitutes the parameter of
ActionMapping for the name in submit and adds the value of name to the
parameter in ActionMapping. SimpleDispatchAction avoids all of this by
strip mining the name in submit, image, file, link, etc. and leaving the
value in the request parameter and the value of the parameter in the
MappingAction to be whatever you want.
I think myself that some of these classes are just good ideas and really
should not be in the Struts application. If you start putting these in
you will just, I think, bloat Struts unnecessarily. If someone wants
these, they should be available on the wiki or whatever. However, if
you think they should go into the Struts application itself, then I
don't think the suggestion really works. You simply have way too much
baggage in DispatchAction for SimpleDispatchAction. If you wanted to
refactor by reversing the situation and making SimpleDispatchAction the
superclass, that, I think, works better. But the actual use of these
two classes is so radically different I actually think separating them
entirely would be the best bet. The only thing they have in comom is
the use of the reflection really. That is not much in common. They do
meet similar needs but in radically different ways.
Michael McGrady
Hubert Rabago wrote:
I was actually thinking of playing around with this idea, so that the
way the method is determined is refactored out, similar to how you
(Niall) changed ValidatorActionForm.
Specifically, I'm interested in figuring out if we can refactor it in
such a way that it becomes useful to other Action hierarchies. One of
the issues with using an app-specific base class is that they lose the
functionality provided by the Action subclasses that comes with
Struts. If we can move this code outside of the *DispatchAction
classes, app-specific base classes can take advantage of these
features as well.
Hubert
On Thu, 16 Sep 2004 18:05:46 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Date: 2004-09-16T11:05:45
Editor: NiallPemberton [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: StrutsCatalogSimpleDispatchAction
URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction
no comment
Change Log:
--
@@ -179,5 +179,47 @@
'''Michael !McGrady'''
+
+Seems to me that most of the SimpleDispatchAction duplicates whats
already in the DispatchAction class. If we re-factored DispatchAction so
that the parameter retrieval was moved into a new getParameter() method then
all that would be needed to achieve what you want is a flavour that
overrides the getParameter()/getMethodName() methods.
+
+Something along the lines of ...
+
+{{{
+public abstract class SimpleDispatchAction extends DispatchAction {
+
+ protected String getParameter(ActionMapping mapping,
+ActionForm form,
+HttpServletRequest request,
+HttpServletResponse response) {
+
+return mapping.getParameter();
+
+ }
+
+ protected String getMethodName(ActionMapping mapping,
+ ActionForm form
Re: DispatchAction (was: [Apache Struts Wiki] Updated: StrutsCatalogSimpleDispatchAction)
Hubert,
Is this what has already happened in DispatchAction with the getMethodName()
method that has been added since Struts 1.2.0?
Maybe I've mis-understood what you're saying.
Niall
- Original Message -
From: Hubert Rabago [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Thursday, September 16, 2004 8:23 PM
Subject: RE: DispatchAction (was: [Apache Struts Wiki] Updated:
StrutsCatalogSimpleDispatchAction)
I was actually thinking of playing around with this idea, so that the
way the method is determined is refactored out, similar to how you
(Niall) changed ValidatorActionForm.
Specifically, I'm interested in figuring out if we can refactor it in
such a way that it becomes useful to other Action hierarchies. One of
the issues with using an app-specific base class is that they lose the
functionality provided by the Action subclasses that comes with
Struts. If we can move this code outside of the *DispatchAction
classes, app-specific base classes can take advantage of these
features as well.
Hubert
On Thu, 16 Sep 2004 18:05:46 -, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Date: 2004-09-16T11:05:45
Editor: NiallPemberton [EMAIL PROTECTED]
Wiki: Apache Struts Wiki
Page: StrutsCatalogSimpleDispatchAction
URL: http://wiki.apache.org/struts/StrutsCatalogSimpleDispatchAction
no comment
Change Log:
--
@@ -179,5 +179,47 @@
'''Michael !McGrady'''
+
+Seems to me that most of the SimpleDispatchAction duplicates whats
already in the DispatchAction class. If we re-factored DispatchAction so
that the parameter retrieval was moved into a new getParameter() method then
all that would be needed to achieve what you want is a flavour that
overrides the getParameter()/getMethodName() methods.
+
+Something along the lines of ...
+
+{{{
+public abstract class SimpleDispatchAction extends DispatchAction {
+
+ protected String getParameter(ActionMapping mapping,
+ActionForm form,
+HttpServletRequest request,
+HttpServletResponse response) {
+
+return mapping.getParameter();
+
+ }
+
+ protected String getMethodName(ActionMapping mapping,
+ ActionForm form,
+ HttpServletRequest request,
+ HttpServletResponse response,
+ String parameter) {
+
+if((parameter != null) (parameter.endsWith(.x))) {
+ methodName = parameter.substring(0,parameter.indexOf('.'));
+} else {
+ Enumeration enum = request.getParameterNames();
+ while(enum.hasMoreElements()) {
+buttonValue = (String)enum.nextElement();
+if(buttonValue.endsWith(.x)) {
+ methodName =
buttonValue.substring(0,buttonValue.indexOf(.x));
+}
+ }
+}
+return methodName;
+ }
+
+}
+
+}}}
+
+'''Niall Pemberton'''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Niall Pemberton wrote: I don't see anything radically different in SimpleDispatchAction to the other DispatchAction flavours - it just uses a slightly different mechanim for determining the method name to execute and it doesn't throw an exception if the parameter is null. Thatt slightly different mechanism changes pretty much completely how you can relate to the view. _/*You have to remember that these two classes are obtaining the method name from different places*/_. Remember too that SimpleDispatchAction does not merely replace DispatchAction, it replaces DispatchAction, LookupDispatchAction and MappedDispatchAction. That should show that, while it may (and does) look like a simple change (and is a simple change) the results are radically different because of how it relates to the view. For example: With SimpleDispatchAction, for /any /number of methods, you might have a struts-config.xml that looks like: | action path=/subscription type=org.example.SubscriptionAction /action| With MappingDispatchAction, for a create, edit, save, delete, and list set of methods, you would have to have the following: | action path=/createSubscription type=org.example.SubscriptionAction parameter=create forward name=success path=/editSubscription.jsp/ /action action path=/editSubscription type=org.example.SubscriptionAction parameter=edit forward name=success path=/editSubscription.jsp/ /action action path=/saveSubscription type=org.example.SubscriptionAction parameter=save name=subscriptionForm validate=true input=/editSubscription.jsp scope=request forward name=success path=/savedSubscription.jsp/ /action action path=/deleteSubscription type=org.example.SubscriptionAction name=subscriptionForm scope=request input=/subscription.jsp parameter=delete forward name=success path=/deletedSubscription.jsp/ /action action path=/listSubscriptions type=org.example.SubscriptionAction parameter=list forward name=success path=/subscriptionList.jsp/ /action | Additionally, what will occur on the page will be completely different. That does not mean a link won't be a link and a file browse won't be a file browse, etc. What it means is that the view code will be broken. I am a pretty good coder and sometimes not the best communicator on these things because I tend to come from a different angle, being self-trained. Rick Reumann is changing some things to use this instead of MappingDispatchAction, I think. Maybe he can be helpful to you on this. Michael McGrady | | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Hubert Rabago wrote:
public ActionForward execute(_usual_params) {
RequestUtils.dispatch(this, _usual_params);
}
This will work fine for SimpleDispatchAction, in fact I LOVE IT and I am
going to do it, if you don't, but this would not replace DispatchAction,
LookupDispatchAction or MappingDispatchAction, and there probably is a
lot of code out there with those actions. You would have to provide the
following four options.
RequestUtils.dispatch(this,_usual_params);
RequestUtils.lookupDispatch(this,_usual_params);
RequestUtils.mappingDispatch(this,_usual_params);
RequestUtils.simpleDispatch(this,_usual_params);
I want to emphasize, however, that
RequestUtils.simpleDispatch(this,_usual_params) will do everything that
the others do and do what they do more simply, but it is based on
different data.
Michael
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Tom Drake wrote: It appears that what we have are different strategies for determining the method name. Yes! *_/The existing classes use DIFFERENT DATA AND DIFFERENT LOGIC to get the method name/_*. The ONLY thing SimpleDispatchAction and the present classes have in common is that they do get the method name and that they use reflection once they have the method name. The present classes use a combination of a request parameter value from a name/value pair with the value of an ActionMapping parameter property to determine the method. SimpleDispatchAction uses neither of these sources and so, requires no special coding in struts-config.xml and frees up the related values for the name/value pairs in a href=, input type='submit', input type='image and input type='file for whatever clever machinations we coders can create. The SimpleDispatchAction, if it were not for legacy uses, can completely replace the three existing dispatch classes. Enough from me. I am too noisy. Right? Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Niall Pemberton wrote: You're making the assumption that everyone wants to do things the way you do - SimpleDispatchAction doesn't replace any of them if people don't. Personally (if I used them :-)) MappingDispatchAction looks good to me for most use cases or if I didn't want to specify anything in the struts-config.xml then have a custom DispatchAction that just always used method as the parameter name to find the method name from the request. Niall I guess I am not communicating well at all. I have no idea what people want to do and not only am I aware that people are not very predictable but also that I have no desire to try to get people to do anything whatsoever. I can tell you that also having been a Federal Public Defender I am really, really aware of the variety of choices people will make. ;-) I just am saying that for my money a class that does exactly the same thing as three other classes and is faster, lighter, and less coupled is preferrable to me. I also suspect it will be preferrable to others, if that is right. So, I assumed the only issue was whether it was better, and not whether people liked things that were not better. I would give people the dignity of arguing with them a bit about it, if they disagree, in order to see what they are thinking. I am not sure, Niall, that you see what is happening in this case, given you previous posts, but let me say that the logic in SimpleDispatchClass replaces the logic in all these other cases and gives you more flexibility. If you prefer to have to code the struts-config.xml when you don't have to and if you prefer to have heavier code in an underlying super class, and if you prefer to have a situation where you cannot use a single solution to all uses of buttons, then you won't want to use SmpleDispatchAction. But, if you do like your code to be simple, lightweight, generic, and fairly straightforward, you might try SmpleDispatchAction. Do you see that you can do exactly the same thing with SimpleDispatchAction as with MappingDispatchAction and without the heavy load of DispatchAction? Do you see also that you can do exactly the same thing with SimpleDispatchAction as all three of these classes? Heck, if you see all this and prefer to use those classes, I would be surprised but would not be plussed. (Is there a plussed to go with nonplussed?) The preceding sardonic presentation is meant to be a bit comical, but I would be interested, Niall, in knowing why you would do what you say you would, given what seems to be a pretty decided inferiority of the classes you say you would use. I may well be completely wrong in my assessment and would welcome any critique you have to offer. Maybe I too should do what you suggest, but I cannot see it. Laughin' and Lovin' inWashington, Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DispatchAction
Michael, Quick comments on your suggestion. Please don't mistake the brevity for abruptness - just lack of time on my part. I agree with pretty much everything Niall said in his previous reply, with the following 2 cents-worth. 1. Big reason for not including this as a standard action is the use of '.x' to identify the method name to dispatch to. The .x suffix has a particular meaning in HTML (i.e. Image Button) and it would be incorrect/misleading to subvert it for other uses that have nothing to do with image buttons. 2. I don't *want* to use '.x'. I don't like using DispatchAction much because it pollutes my URLs. MappingDispatchAction let's me keep the URLs nice and tidy at the expense of slightly more configuration in the config file, but I'm OK with that trade-off. 3. The example code doesn't work for SimpleDispatchAction. You are not passing the ActionMapping parameter to the getMethodName method, which requires it. Could you update the wiki with the correct code? If you're proposing this as an additional action that *some* people might find useful, then that's great. But I think you were suggesting this as a *replacement* for DispatchAction/LookupDispatchAction/MappingDispatchAction, but it simply does not do what those actions already do and so could not replace them. Also, I would not be happy with inclusion in Struts because of the non-standard use of HTML. regards, Steve -Original Message- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: September 16, 2004 5:54 PM To: Struts Developers List Subject: Re: DispatchAction Niall Pemberton wrote: You're making the assumption that everyone wants to do things the way you do - SimpleDispatchAction doesn't replace any of them if people don't. Personally (if I used them :-)) MappingDispatchAction looks good to me for most use cases or if I didn't want to specify anything in the struts-config.xml then have a custom DispatchAction that just always used method as the parameter name to find the method name from the request. Niall I guess I am not communicating well at all. I have no idea what people want to do and not only am I aware that people are not very predictable but also that I have no desire to try to get people to do anything whatsoever. I can tell you that also having been a Federal Public Defender I am really, really aware of the variety of choices people will make. ;-) I just am saying that for my money a class that does exactly the same thing as three other classes and is faster, lighter, and less coupled is preferrable to me. I also suspect it will be preferrable to others, if that is right. So, I assumed the only issue was whether it was better, and not whether people liked things that were not better. I would give people the dignity of arguing with them a bit about it, if they disagree, in order to see what they are thinking. I am not sure, Niall, that you see what is happening in this case, given you previous posts, but let me say that the logic in SimpleDispatchClass replaces the logic in all these other cases and gives you more flexibility. If you prefer to have to code the struts-config.xml when you don't have to and if you prefer to have heavier code in an underlying super class, and if you prefer to have a situation where you cannot use a single solution to all uses of buttons, then you won't want to use SmpleDispatchAction. But, if you do like your code to be simple, lightweight, generic, and fairly straightforward, you might try SmpleDispatchAction. Do you see that you can do exactly the same thing with SimpleDispatchAction as with MappingDispatchAction and without the heavy load of DispatchAction? Do you see also that you can do exactly the same thing with SimpleDispatchAction as all three of these classes? Heck, if you see all this and prefer to use those classes, I would be surprised but would not be plussed. (Is there a plussed to go with nonplussed?) The preceding sardonic presentation is meant to be a bit comical, but I would be interested, Niall, in knowing why you would do what you say you would, given what seems to be a pretty decided inferiority of the classes you say you would use. I may well be completely wrong in my assessment and would welcome any critique you have to offer. Maybe I too should do what you suggest, but I cannot see it. Laughin' and Lovin' inWashington, Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DispatchAction
IMHO DispatchActions are more of a programmer convenience, than an additional level of controller. I don't use them to dynamically select the action at runtime (the job of the controller), just to let me organize code together and avoid duplication where the code seems to belong together. (e.g. CRUD operations). In particular, with the MDA, the action is determined exclusively from the action path not from request parameters. Exactly the same as using standard, separate actions but - in some cases - more convenient. Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: September 16, 2004 7:59 PM To: Struts Developers List Subject: Re: DispatchAction I guess this thread has come to the point where I just have to throw in my 2 cents worth... ;-) IMHO, dispatch actions, whatever flavour, are a bad idea in the first place. They are essentially second-level controllers. What for? You already have a perfectly good controller in the Struts ActionServlet, so why have your own additional levels of controller below that? It only complicates the mechanism by which an incoming request is handed off to the relevant body of code, and confuses people trying to understand how the application works. As for which of SimpleDA, MappingDA, FubarDA, whatever, is the best, all I have to say is that exposing the names of non-trivial Java methods in URLs, and so visible outside the container, makes me very queasy from a security perspective. So if I was forced to use a dispatch action, I would certainly choose one that did not rely on a query string parameter to specify the method name. -- Martin Cooper On Thu, 16 Sep 2004 17:54:03 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Niall Pemberton wrote: You're making the assumption that everyone wants to do things the way you do - SimpleDispatchAction doesn't replace any of them if people don't. Personally (if I used them :-)) MappingDispatchAction looks good to me for most use cases or if I didn't want to specify anything in the struts-config.xml then have a custom DispatchAction that just always used method as the parameter name to find the method name from the request. Niall I guess I am not communicating well at all. I have no idea what people want to do and not only am I aware that people are not very predictable but also that I have no desire to try to get people to do anything whatsoever. I can tell you that also having been a Federal Public Defender I am really, really aware of the variety of choices people will make. ;-) I just am saying that for my money a class that does exactly the same thing as three other classes and is faster, lighter, and less coupled is preferrable to me. I also suspect it will be preferrable to others, if that is right. So, I assumed the only issue was whether it was better, and not whether people liked things that were not better. I would give people the dignity of arguing with them a bit about it, if they disagree, in order to see what they are thinking. I am not sure, Niall, that you see what is happening in this case, given you previous posts, but let me say that the logic in SimpleDispatchClass replaces the logic in all these other cases and gives you more flexibility. If you prefer to have to code the struts-config.xml when you don't have to and if you prefer to have heavier code in an underlying super class, and if you prefer to have a situation where you cannot use a single solution to all uses of buttons, then you won't want to use SmpleDispatchAction. But, if you do like your code to be simple, lightweight, generic, and fairly straightforward, you might try SmpleDispatchAction. Do you see that you can do exactly the same thing with SimpleDispatchAction as with MappingDispatchAction and without the heavy load of DispatchAction? Do you see also that you can do exactly the same thing with SimpleDispatchAction as all three of these classes? Heck, if you see all this and prefer to use those classes, I would be surprised but would not be plussed. (Is there a plussed to go with nonplussed?) The preceding sardonic presentation is meant to be a bit comical, but I would be interested, Niall, in knowing why you would do what you say you would, given what seems to be a pretty decided inferiority of the classes you say you would use. I may well be completely wrong in my assessment and would welcome any critique you have to offer. Maybe I too should do what you suggest, but I cannot see it. Laughin' and Lovin' inWashington, Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: DispatchAction
Hi, Niall, Thanks for the discussion. I have a few things to say on it which might be of interest. I will be brief. * It doesn't do EXACTLY the same as MappingDispatchAction or DispatchAction (I'm ignoring LookupDispatchAction 'coz I don't like it). It almost does the same as MappingDispatchAction except that MappingDispatchAction requires the method name in the struts-config.xml and throws an Exception if it isn't there. If you like doing this with MappingDispatchAction, then you can do it with SimpleDispatchAction as well. It /is/ the same in this regard, Niall. I am not sure why you think it isn't.. You don't /have /to do it but you can configure SimpleDispatchAction so that it will do exactly what MappingDispatchAction does in this regard. I think it will in all regards. I cannot imagine, given what I know of both classes, what would be an exception in this regard. DispatchAction also throws an Exception if theres no parameter in struts-config.xml and uses the parameter to find the name from the Request. Can't see how you can say SimpleDispactgAction does exactly the same thing - it doesn't. The logic, of course, is different. And, SimpleDispatchAction does things the others don't. But, so far as I can see, if you want the behaviors of the other three, SimpleDispatchAction provides it. I have not seen yet how it does not. * I don't see how its faster or lighter - most of its code is just a duplication of whats in DispatchAction and the only difference is the determination of the method name. Because of the way the value of the parameters are displayed, in LookupDispatchAction you have to have this whole initLookupMap code that is significant, I think. In MappingDispatchAction you have to have all the code for the various paths. You may want that. And, if you do, it is available with SimpleDispatchAction, but it is not necessary and is heavier. I might have overstated how heavy, but my prejudice is to get simple and light always. * If I used dispatch actions I would create my own custom one that always used method as the parameter name to get the method name from the Request. I'm sure that would suit most situations, would mean nothing was required in struts-config..xml and the custom action wouldn't have to go through all the request parameters find one that ended in .x You can do this, of course, but you would sacrifice a lot of flexibility in solving problems that I see people struggle with constantly on the list. Indeed, SimpleDispatchAction was born recently out of an attempt to assist another engineer engaged in such a struggle. I put a lot of stock in providing an easy architecture to the view team. This solution gives them a simple solution and has no downside that I know of to date. Well given that I don't use them its probably a bit rich stating my preferences :-) but anyway. MappingDispatchAction looks OK to me - if I hated specifying stuff in the struts-config.xml then I wouldn't be using Struts. Also seems to me that having different paths for each of the actions would be a good thing - my app controls user access based on the path - so having /save.do and /delete.do with different parameters seems like a better idea than just having one action mapping. Anyway I was never argueing for this - but its different and I thinks its a valid option for people to have. It is one thing to hate specifying stuff in the struts-config.xml file but another to have to do so in order to meet certain problem domains. SimpleDispatchAction removes the necessity and takes away nothing that I know of to date. I don't get the heavy load bit at all, not if you're taling about the actual code in the classes rather than how you configure the xml and view to use them. The multiple mappings mean multiple classes, of course, vis-a-vis MappingDispatchAction. And, the extra coding and the extra methods employed by LookupDispatchAction are what I call heavy. Actually never said I would use them - I don't, I use plain old Action classes and am happy doing so. Yah, they are not necessary. I just determined what method to call by using a utility class to do what SimpleDispatchAction does not and then switches and the if else if else if else if etc. in the past. I have found out that using SimpleDispatchAction gives me much more speed. I was amazed, actually. The code is also a lot easier to read. public ActionForward update() is a lot easier to follow in an action class than else if(SiteConstant.UPDATE.equals(method)) for me. So, I like the DispatchAction idea of using reflection. I just hated the complexity and the inflexibility of the way the name of the method to be employed. The biggest use for LookupDispatchAction is to get around the problem of there being an .x and a .y with input type='image', after all. I just tried to turn the problem into a plus. And, so far, I think I have. I am not trying to change your mind, but
Re: DispatchAction
Martin Cooper wrote: IMHO, dispatch actions, whatever flavour, are a bad idea in the first place. They are essentially second-level controllers. What for? You already have a perfectly good controller in the Struts ActionServlet, so why have your own additional levels of controller below that? It only complicates the mechanism by which an incoming request is handed off to the relevant body of code, and confuses people trying to understand how the application works. The problem that dispatch actions are primarily related to, Martin, is determining which submit or image type was pressed when a form is submitted. The problem is that you have to find out what the parameter is (it could be various things) and not what the value of a parameter is. The controller is not set up for this. The controller cannot do this. I agree that the usual way of doing this confuses people. Other ways, using Button classes in ActionForms, for example, which I have discussed at length elsewhere, is a really heavy and slow solution. I find SimpleDispatchAction or the associated ImageTagUtil, which does not use Action code at all clear and good ways to do this. You cannot avoid the problem. The problem is real. How do you solve it? JavaScript? Given the available solutions I have seen in Struts, which are: LookupDispatchAction, Button classes outside the ActionForm, Button class as an inner class in the ActionForm, ImageTagUtil, and SimpleDispatchAction, I vastly prefer the last two. That's why I coded them, of course, so I am prejudiced. As for which of SimpleDA, MappingDA, FubarDA, whatever, is the best, all I have to say is that exposing the names of non-trivial Java methods in URLs, and so visible outside the container, makes me very queasy from a security perspective. So if I was forced to use a dispatch action, I would certainly choose one that did not rely on a query string parameter to specify the method name. I am not sure what exposed methods you are talking about. This is not required at all. Thanks for you contribution to this. I am glad you weighed in. It is impossible to tell what silent people think. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchAction
Steve Raeburn wrote: Quick comments on your suggestion. Please don't mistake the brevity for abruptness - just lack of time on my part. I don't. I appreciate all this feedback and discussion. I like the idea of ideas being honed and forged with discussion and criticism. It is a good thing and I know we all have limited time. 3. The example code doesn't work for SimpleDispatchAction. You are not passing the ActionMapping parameter to the getMethodName method, which requires it. Could you update the wiki with the correct code? You are wrong about this. The code presently is running and working fine on my application. I know why you think this, but your conclusion is based on the same misconception everyone else has had when they first see SimpleDispatchAction. It does not work the way they think. This uses a really unusual twist which results in some surprising and not immediately understandable logic. If you're proposing this as an additional action that *some* people might find useful, then that's great. But I think you were suggesting this as a *replacement* for DispatchAction/LookupDispatchAction/MappingDispatchAction, but it simply does not do what those actions already do and so could not replace them. This is, I think, false. I think maybe you don't see what SimpleDispatchAction does, Martin. Members on the user list have adapted it, in fact, in place of all those actions. We are not used to seeing what it means to look for a name in a name/value pair. This is a fundamental change in what we do. It has been there to do, of course, and so is not invented. But, SimpleDispatchAction does it and the results are cool, I think. Doing so allows really powerful things to happen and creates surprising flexibility. 1. Big reason for not including this as a standard action is the use of '.x' to identify the method name to dispatch to. The .x suffix has a particular meaning in HTML (i.e. Image Button) and it would be incorrect/misleading to subvert it for other uses that have nothing to do with image buttons. I agree in a sense with this, and I would not be surprised if someone wanted to use a different class for those cases where there is no .x just for this reason. However, let me tell you how this all happened. First, I wanted to solve the problem of the .x case, which LookupDispatchAction does, I think, in a cool but ugly fashion. I tried Button classes but they were too heavy. They really bog down performance, actually. Then I tried an inner Button class in the ActionForm, which is associated with ImageTagUtil for historical or hysterical reasons on the wiki StrutsCatalog. This was better. Finally, I realized that the simple solution in ImageTagUtil was the best. Just mind, retrieve, get the value with .x and be done with it. So I did. This leads to the usual series of choices in the Action and associated classes for various methods, e.g. as in CRUD, etc. That too was surprisingly slow, if you did not want to hard code values in the if and else if choices. And, the code really got hard to read if there were significant numbers of methods. This was really flexible though. Then, following some prompting by people on the lists with their problems, I began to seek a generic button solution. That mean using .x throughout for consistency, even if this was not required. But, that led me to a further discover beyond the scope of this note, viz. that leaving the value of the .x name free for other uses created a whole new kind of logic I had not even considered before with all sorts of interesting possibilities. Instead of getting one value from a name/value pair, I was getting two values which could be assciated or not. There is more, but you get the picture. I have a very interesting whole application dealing with images and buttons which will be on the table in the near or not too distant future with some surprising aspects which really aid development, I think. Also, I would not be happy with inclusion in Struts because of the non-standard use of HTML. I am on record as being of the opinion that I think nothing like this should be included with Struts but should be provided as possible code in wikis, etc., so I agree. I just thought that if you were going to have three classes where one would do, you might want that. I am not sure why you think the HTML used is non-standard, however. You mean the use of names like update.x? The HTML is standard. The protocol for the values of the request name/value pairs is just expanded to four rather than one option in the semantics, leading to the flexibility previously discussed. IMHO that LookupDispatchAction actually distorts normal practice with less benefits. Thanks again for all your thought put into this. I appreciate it a great deal and have enjoyed your posts over the time I have been around. That goes for the other people assisting in this aa well. Michael
Re: DispatchAction
Steve Raeburn wrote: IMHO DispatchActions are more of a programmer convenience, than an additional level of controller. I don't use them to dynamically select the action at runtime (the job of the controller), just to let me organize code together and avoid duplication where the code seems to belong together. (e.g. CRUD operations). With LookupDispatchAction and with SimpleDispatchAction, you get a solution to the problem of multiple images. That is something that is particularly important, and is necessarily related to distinguishing either between utility classes or differing methods. No? In particular, with the MDA, the action is determined exclusively from the action path not from request parameters. Exactly the same as using standard, separate actions but - in some cases - more convenient. This and other options are equally available with SimpleDispatchAction and statements to the contrary have not seen what is happening with SimpleDispatchAction or have not see what can be done with the flexibilty available. Michael McGrady - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
