Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Ted, tnanks for your reply. This action was just an idea from me. I haven't thought about including it into the struts stuff. Nevertheless I am pleased if it happens and somebody find it usefull. Dmitri Valdin Datum: 24.11.2001 17:32 An:Struts Developers List [EMAIL PROTECTED] Antwort an:Struts Developers List [EMAIL PROTECTED] Betreff: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons Nachrichtentext: Dmitri, I ~really~ like the way this Action works. * It keeps control in the Struts-config, and does not embed presentation details into Action source code. * A single mapping could dispatch every HTML form using a given ActionForm bean. Or, one could choose to use more mappings and fewer local forwards, as preferred. * Each local forward can go to a different ActionMapping, or to the same one with different query strings, or any combination of either approach. * It is easily adapted for those nasty image buttons and also shows when they are being used. It is similar to a RelayAction that I use quite a bit, but turns things around. I'd like to adopt it into my Scaffold package as findForwardAction. (There may be other use-cases beyond buttons that haven't occurred yet.) Would that be all right? Of course, the author credit would be yours, and the license is ASF. -Ted. -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
- Original Message - From: Ted Husted [EMAIL PROTECTED] preference. Therefore I like throwing a ServletException better. Any other pros/cons to either approach? The Action is the highest layer, and there is no guarantee that there will be a JSP with an error directive. D'oh. Yeah, I wasn't really thinking through this fully. But I still think throwing a ServletException would give the browser more information although only really useful for debugging. Go ahead and morph my class to have the sendError way. What is the status of these two base classes now? Will you, Ted, refactor the getMethod stuff and commit them? Or what else is needed before they are committable? Also you can go ahead and rearrange the order of the parameters and put 'key' last in mine to keep it consistent. I guess that brings up another issue that has probably been brought up before - extensible logging such that anything logged from a Struts class would go through a layer that would allow our own logging to be plugged into it rather than just logging to the server log. Or is there already a way to do that? Thanks, Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Erik Hatcher wrote: - Standardizing on the class names. I suggest yours be renamed LookupDispatchKeyAction, since LookupAction is pretty generic and there will be several lookup style base classes. I'd like to keep the dispatch moniker out of this one, since it makes it sounds like it uses the reflective dispatch mechanism. But LookupKeyAction works for me. The other could be shortened to DispatchKeyAction, if you like. - Unifying how we deal with getMethod and invokeMethod into a common base-class or via a helper utility class. No point in all our classes having cut and pasted code. My suggestion is to have a common DispatchAction base class for all of our lookup base classes where the getMethod can be added more generically in some way. The issue here is, of course, how to deal with subclasses that want to find different method signatures. I used an Object[] in my class - maybe thats the way to go, or some derivation thereof. All that perform knows, that another method would not, is in the original signature. I do sometimes extract information from the mapping or request, and then pass that back to a method with an extended signature, but I think in practice that would be another dispatch mechanism, and both techniques would not be used at the same time. Do you have a use-case for this feature? As it stands, we could extract into another method the fragment from the orignal DispatchAction below // Identify the method object to be dispatched to and pass it the name to end the method. Another class could then extend DispatchAction, override perform, obtain its own method name in its own way, and then call that same method at the end. One other comment - I currently prefer using the reflection dispatching because I'd rather not see a whole bunch of 'if' statements like if (button.add.equals(key)), but I definitely agree that its useful to have a more generic dispatch just passing the key. Personally, I've started to specify lightweight helper objects as the parameter property. A single standard Action can then instantiate and invoke these objects from within perform. Additional standard functionality is specified through ActionForwards. While this can leads to a larger configuration file, it severly reduces the number of Struts Actions in the game, and enforces the use of business objects. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Erik Hatcher wrote: Obviously my only use-case/need right now is to have an additional String key parameter passed to a perform-like method. So I'm ok with locking it into that method signature if that'll get it committed, but I still think a DispatchAction subclass should be more extensible than that. Maybe you're proposing something more extensible and I'm just not seeing it yet though. The String key would be passed up in LookupKeyAction version, and developers using this one would subclass the extended perform method. With DispatchKeyAction, the key is used to call the method itself and does not need to be passed. Since reflection is being used, the key is implicit in the name of the method invoked. In order to pass a parameter, it has to come from somewhere. Everything that perform knows is in the original signature, where any reflected method can get it. Actions often need to pull properites and parameters out of the request and mappings. But this is best handled by other utility methods in the class, that each reflective method could call. So if the use-case is I want to pass glockenspeil from the request, then the class should have a protected String getGlockenspiel(request) method that any of the reflective methods could call (and an additional subclass could override). I've annexed a DispatchAction with the initial refactoring I mentioned. The idea is that you could start by extending this, overriding perform with your own method-name discovery routine, and then call return dispatchMethod(mapping,form,request,response,name); at the end (without calling super.perform(...) at any point). Of course, additional refactoring to encapsulate error handling could be done, since we call the same sendError block several times, but it would just be more instances of extract method. And some point between Struts 1.x and Struts 2.x, I'd like apply a great many instances of extract method throughout the framework, since many of our methods are a trifle long. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ DispatchAction.java Description: application/unknown-content-type-visualcafefile.document -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
- Original Message - From: Ted Husted [EMAIL PROTECTED] Personally, I would then consider the keys a form of input and make them part of the ActionForm. But then we are back to having the Action have a whole bunch of 'if' statements for each key. Sure, a new ActionForm base-class would be handy to take care of the key lookup, but it doesn't solve the dispatching problem. The button indicates which action to perform, and having the Action class handle it seems appropriate. Even with an enhanced ActionForm it would require coding in Action also. Why not do it all in a smart Action base class? What do you mean by annexed? I don't see it anywhere in CVS? I meant attached. Oops, sorry got it. I still am lobbying for 'key' to be included in the method invoked by DispatchKeyAction. Pretty please? Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Erik Hatcher wrote: Oops, sorry got it. I still am lobbying for 'key' to be included in the method invoked by DispatchKeyAction. Pretty please? I obviously don't understand the use-case well enough to have a reasonable opinion. Needing the keys passed as parameter confuses me, since the class already has all that information. Why muddy the signature and tell it something it already knows? Everything is happening within the same object. Using the original example, the parameter action is still going to be set to the button's label, and any method of the class can look that up whenever they want. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Dmitri, I ~really~ like the way this Action works. * It keeps control in the Struts-config, and does not embed presentation details into Action source code. How are presentation details embedded in the LookupAction you posted and my similar code? Its just a key that it exposes, which is a bridge between the view and the controller, much like an ActionForm is also. * A single mapping could dispatch every HTML form using a given ActionForm bean. Or, one could choose to use more mappings and fewer local forwards, as preferred. * Each local forward can go to a different ActionMapping, or to the same one with different query strings, or any combination of either approach. You guys sure do like big ugly struts-config.xml files! I still feel (and of course this is a preference issue at this point) that its bordering on, if not already past, putting business-specific logic in struts-config by doing this kind of thing. But have fun with this if you like! :) * It is easily adapted for those nasty image buttons and also shows when they are being used. Indeed. I enjoyed Dmitri's stuff, which gave me ideas for enhancing my way by having a base class automatically deal with the .x stuff as well. A couple of comments/questions on Ted's LookupAction: - Any particular reason why the last one wins in your loading of the key mappings? Ideally there would not be duplicates, but I prefer the first one wins (although I have no strong preference, it just seems friendlier to allow the first one for some reason). - Why use the response.sendError? I realize this is done elsewhere in Struts, but I much prefer to allow exceptions to climb back up and let higher layers deal with them if possible, and having it kick back to the JSP page and letting the errorPage directive catch it and forward on would be my preference. Therefore I like throwing a ServletException better. Any other pros/cons to either approach? - Any preference to the position of the key parameter on the template patternered 'perform' method? I put mine first, and you switched yours to last. I have no preference, just curious on why the switch. Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Ted Husted wrote: Here's a first blush at a separate LookupAction that doesn't use the reflection techniques from DispatchAction. Attached, this time. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ LookupAction.java Description: application/unknown-content-type-visualcafefile.document -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Erik Hatcher wrote: - Any particular reason why the last one wins in your loading of the key mappings? Ideally there would not be duplicates, but I prefer the first one wins (although I have no strong preference, it just seems friendlier to allow the first one for some reason). Given the use-case and the small number of items involved, it didn't seem worthwhile to check for duplicates. - Why use the response.sendError? I realize this is done elsewhere in Struts, but I much prefer to allow exceptions to climb back up and let higher layers deal with them if possible, and having it kick back to the JSP page and letting the errorPage directive catch it and forward on would be my preference. Therefore I like throwing a ServletException better. Any other pros/cons to either approach? The Action is the highest layer, and there is no guarantee that there will be a JSP with an error directive. - Any preference to the position of the key parameter on the template patternered 'perform' method? I put mine first, and you switched yours to last. I have no preference, just curious on why the switch. Just the general idea that extensions add on to the end. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
*whew* - much better! :) Except that I don't prefer the method you describe because of its increased footprint in struts-config.xml - but we've already covered that issue. I'll try to submit the first two of the four dispatch base classes I proposed in a day or so - they will just be a refactoring and split of the one I already submitted. Erik - Original Message - From: Dimitri Valdin [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 5:17 AM Subject: Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons sorry, I have really misunderstood the DispatchAction. Thank's Erik for pointing it out. In case of MultiSubmitAction working with DispatchAction, the solution would be: actionpath=/test type=org.apache.struts.actions.MultiSubmitAction name=testForm scope=request input=/test.jsp forward name=add.x path=/addDelete.domethod=add/ forward name=delete.x path=/addDelete.domethod=delete/ /action actionpath=/addDelete type=org.apache.struts.webapp.example.AddDeleteAction name=testForm parameter=method scope=request input=/test.jsp /action Dmitri Valdin -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
well, but now, in case of using DispatchAcion this footprint is really small, I would say, that it is not much bigger, than implementing getKeyMethodMap() ;-) Right, you have one additional action mapping in struts-config than my design. I have mappings in the subclass via getKeyMethodMap, and strings in ApplicationResources. Putting labels in ApplicationResources is something that really should be done anyway so no real difference there. In your design you have to name each button differently, whereas in mine, they all have the same name, but different values. In your design you have to deal with the .x stuff explicitly. In mine, I'll have my base class (I haven't written the one for different named buttons yet, but will eventually) deal with it automatically so it will be hidden from the designer and developer of the Action subclasses. I just don't feel that struts-config is the appropriate place to deal with those kinds of mappings as they are very concrete to the action. A matter of preference, I suppose. Is that a fair enough summary? I still like my design better! :) But yours works and certainly is a viable alternative. Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
I just don't feel that struts-config is the appropriate place to deal with those kinds of mappings as they are very concrete to the action. A matter of preference, I suppose. Is that a fair enough summary? Sure. I still like my design better! :) But yours works and certainly is a viable alternative. Thanks :-) It was an interesting discussion. Cheers, Dmitri -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Dmitri,
you solution is very interesting, but I am not absolutely happy with the
fact,
that control is specified not only in struts-config.xml but in source code
as well (map definition).
I don't think my solution takes control away from struts-config, it only
gives the action more control over how it handles things directed towards
it.
Even application properties play here an important
role.
I don't understand what you mean by application properties playing a role.
How so?
More comments in-line below
I have tried to use your ideas and produced very simple solution which
would
satisfy
both buttons and images needs.
struts-config.xml
=
actionpath=/test
type=org.apache.struts.actions.MultiSubmitAction
name=testForm
scope=request
input=/test.jsp
forward name=add.x path=/add.do/
forward name=delete.x path=/delete.do/
/action
Definitely an interesting indirection mapping scheme... but that means that
for
every form there is an action mapping, and another action class and mapping
for each button on the form. struts-config.xml will already be huge in our
application of hundreds of forms, so having a single mapping per form is
important not only to keep the config smaller, but to keep it clearer.
Your solution does accomplish the multi-button issue by naming each button
uniquely. I feel more comfortable with each button having the same name,
but I suppose that is a matter of preference (and as such is accounted for
in the two base classes I'm proposing). In your case you'd have to be
careful not to have a property of your form bean with the same name as any
of the button names - in my design you'd just have to make sure not to have
one form bean property (i.e. action).
MultiSubmitAction.java
==
public class MultiSubmitAction extends Action {
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
String forwards[] = mapping.findForwards();
for (int i = 0; i forwards.length; i++) {
if (request.getParameter(forwards[i]) != null) {
// Return the required ActionForward instance
return mapping.findForward(forwards[i]);
}
}
// Go back to input (any other ideas ?)
return new ActionForward(mapping.getInput());
Ideas - How about returning ActionErrors if the mapping isn't found? Or I
personally would throw a JspException since this is truly a situation that
cannot be handled wisely by the action in all cases and represents a
situation that should not happen.
Some considerations:
If you never intend to use images, then you can omit .x suffix.
In your design, struts-config.xml will have to be modified if a designer
switches between using a graphic button and text buttons by adding or
removing the .x, or as in your example, name text buttons with .x on
them - which I don't prefer. My goals are to make the designers life as
easy and straightforward as possible, and having text buttons named .x
just doesn't make a lot of sense without knowing whats going on under the
hood. A designer shouldn't have to care what is going on under the hood.
If somebody wants to have all methods stored in one file he can subclass
DispatchAction
and play with parameter property:
actionpath=/add
type=org.apache.struts.webapp.example.AddDeleteAction
name=testForm
parameter=add
scope=request
input=/test.jsp
/action
actionpath=/delete
type=org.apache.struts.webapp.example.AddDeleteAction
name=testForm
parameter=delete
scope=request
input=/test.jsp
/action
I don't think using DispatchAction as you suggest will work. What it
would do in the add case is this:
- call request.getParameter(add) - what would that return in your case?
The text of the button.
- Then it would attempt to look up a method named the text of the button.
This is not a very plausible scenario because the button labels need to be
separated from the action, and not considered (directly), and of course its
unlikely you'd name your methods appropriately, since you couldn't have a
method named Add Record but that is a very likely button text.
Maybe I'm missing a piece of your design here, but the parameter value used
in DispatchAction uses a level of indirection that I don't see being
accounted for here.
Instead of 'misusing' mappings it might be possible to introduce some
additional tag
to action config:
dispatch property=delete.x path=/delete.do/
or
dispatch property=delete.x method=delete/
I think this kind of mapping puts unnecessary stuff in an already cluttered
Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Erik, I don't understand what you mean by application properties playing a role. How so? buttons.add buttons.delete have to be defined, which is not obvious for somebody who does not take care about internationalization. In fact I would define the resources in any case. But what about images ? How do you want to handle them ? Definitely an interesting indirection mapping scheme... but that means that every form there is an action mapping, and another action class and mapping for each button on the form. struts-config.xml will already be huge in our application of hundreds of forms, so having a single mapping per form is important not only to keep the config smaller, but to keep it clearer. Sure. It is a matter of taste. But perhaps not only. What would happen if one day someone decides to move 2 from 5 submit buttons to another page ? Will you rewrite the class ? Single action are also helpful, if you want to call them from several places, say from context-menu or even through short cuts. I prefer to have all actions defined in separate classes. But this is just my preference and I accept another solutions. // Go back to input (any other ideas ?) return new ActionForward(mapping.getInput()); Ideas - How about returning ActionErrors if the mapping isn't found? Or I personally would throw a JspException since this is truly a situation that cannot be handled wisely by the action in all cases and represents a situation that should not happen. Yes. Throwing exception would be really better. In your design, struts-config.xml will have to be modified if a designer switches between using a graphic button and text buttons by adding or removing the .x, or as in your example, name text buttons with .x on them - which I don't prefer. My goals are to make the designers life as I see no harm in this .x suffix, especially if you work with images. But it is not the most nice in design for sure. I don't think using DispatchAction as you suggest will work. What it would do in the add case is this: - call request.getParameter(add) - what would that return in your case? Sure. It won't work if you don't add .x suffix ;-) dispatch property=delete.x path=/delete.do/ or dispatch property=delete.x method=delete/ I think this kind of mapping puts unnecessary stuff in an already cluttered struts-config.xml file. Having a subclass of my LookupDispatchAction to Absolutely agree with you. I also prefer to 'misuse' forwards ;-) Thank you for your feedback. Dmitri -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
buttons.add buttons.delete have to be defined, which is not obvious for somebody who does not take care about internationalization. In fact I would define the resources in any case. But what about images ? How do you want to handle them ? For images I would put the image name in ApplicationResource.properties and use html:image srcKey=.../ - but I probably wouldn't go to that extreme until localization is needed. Sure. It is a matter of taste. But perhaps not only. What would happen if one day someone decides to move 2 from 5 submit buttons to another page ? Will you rewrite the class ? If buttons move from one page to another you'd have issues in your design as well, unless each page is pointing to the same action - right? It is likely in our application that buttons will be enabled/disabled (by logic in the JSP to conditionally output them). I would have to see a more concrete example of moving buttons from one page to another, as that has many other implications - is it a single ActionForm multi-page wizard-like form? If not then why would buttons move from one action to another? Single action are also helpful, if you want to call them from several places, say from context-menu or even through short cuts. I prefer to have all actions defined in separate classes. But this is just my preference and I accept another solutions. Understandable - and could be accomplished in my design by having the dispatch go to methods, which then delegated its handling to another action class. I certainly do not advocate the same code in multiple places! :) // Go back to input (any other ideas ?) return new ActionForward(mapping.getInput()); Ideas - How about returning ActionErrors if the mapping isn't found? Or I personally would throw a JspException since this is truly a situation that cannot be handled wisely by the action in all cases and represents a situation that should not happen. Yes. Throwing exception would be really better. In your design, struts-config.xml will have to be modified if a designer switches between using a graphic button and text buttons by adding or removing the .x, or as in your example, name text buttons with .x on them - which I don't prefer. My goals are to make the designers life as I see no harm in this .x suffix, especially if you work with images. But it is not the most nice in design for sure. I don't think using DispatchAction as you suggest will work. What it would do in the add case is this: - call request.getParameter(add) - what would that return in your case? Sure. It won't work if you don't add .x suffix ;-) I think there is a misunderstanding here about DispatchAction. request.getParameter(add.x) would return the coordinates where the user clicked (if it was an html:image. Then DispatchAction would try to find a method by that name - and I definitely don't think you'll name methods for each X-coordinate for an image! :) DispatchAction dispatches to the method named by the result of getParameter, and gets the parameter name from struts-config. Another level of indirection is what is accomplished by my LookupDispatchAction (and your first solution). So, where does that leave us with the variants of DispatchAction? Besides Dmitri's feedback, anyone else have opinions on it? Erik -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
For images I would put the image name in ApplicationResource.properties and use html:image srcKey=.../ - but I probably wouldn't go to that extreme until localization is needed. That was the reason, why I wrote that application resources also play an important role in your design. If buttons move from one page to another you'd have issues in your design as well, unless each page is pointing to the same action - right? Sure, but only in jsp pages and struts-config, not in source code. It is likely in our application that buttons will be enabled/disabled (by logic in the JSP to conditionally output them). I would have to see a more concrete example of moving buttons from one page to another, as that has many other implications - is it a single ActionForm multi-page wizard-like form? If not then why would buttons move from one action to another? Of cource not dynamically. But it is quite possible that some designer just wants to redesign pages and move part of functionality to another pages. Understandable - and could be accomplished in my design by having the dispatch go to methods, which then delegated its handling to another action class. I certainly do not advocate the same code in multiple places! :) I would not argue. It is possible in your design. There are always several ways to achieve the same goal. But unfortunately we haven't got any feedback until now ;-) I think there is a misunderstanding here about DispatchAction. Sorry, I have really misunderstood this point. Dmitri -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Hi Erik,
you solution is very interesting, but I am not absolutely happy with the
fact,
that control is specified not only in struts-config.xml but in source code
as well (map definition). Even application properties play here an important
role.
I have tried to use your ideas and produced very simple solution which would
satisfy
both buttons and images needs. This is just an idea, so any feedback is
welcome.
struts-config.xml
=
actionpath=/test
type=org.apache.struts.actions.MultiSubmitAction
name=testForm
scope=request
input=/test.jsp
forward name=add.x path=/add.do/
forward name=delete.x path=/delete.do/
/action
actionpath=/add
type=org.apache.struts.webapp.example.AddAction
name=testForm
scope=request
input=/test.jsp
forward name=success path=/add_results.jsp/
/action
actionpath=/delete
type=org.apache.struts.webapp.example.DeleteAction
name=testForm
scope=request
input=/test.jsp
forward name=success path=/delete_results.jsp/
/action
test.jsp
html:form action=/test
!-- BUTTON --
html:submit property=add.x
bean:message key=button.add/
/html:submit
!-- IMAGE --
html:image page=/images/delete.gif property=delete /
/html:form
MultiSubmitAction.java
==
public class MultiSubmitAction extends Action {
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
String forwards[] = mapping.findForwards();
for (int i = 0; i forwards.length; i++) {
if (request.getParameter(forwards[i]) != null) {
// Return the required ActionForward instance
return mapping.findForward(forwards[i]);
}
}
// Go back to input (any other ideas ?)
return new ActionForward(mapping.getInput());
}
}
Some considerations:
If you never intend to use images, then you can omit .x suffix.
If somebody wants to have all methods stored in one file he can subclass
DispatchAction
and play with parameter property:
actionpath=/add
type=org.apache.struts.webapp.example.AddDeleteAction
name=testForm
parameter=add
scope=request
input=/test.jsp
/action
actionpath=/delete
type=org.apache.struts.webapp.example.AddDeleteAction
name=testForm
parameter=delete
scope=request
input=/test.jsp
/action
Instead of calling return mapping.findForward(forwards[i]) it might be
interesting to instantiate the action, similar to as it is done in
ActionServlet
(protected Action processActionCreate) and just call it's perform() method.
It would be faster for sure.
Instead of 'misusing' mappings it might be possible to introduce some
additional tag
to action config:
dispatch property=delete.x path=/delete.do/
or
dispatch property=delete.x method=delete/
Dmitri Valdin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
We have also implemented a multiple submit button system; but in our case we wrote a custom tag that generates javascript that sets a property to a specified value and submits the form when you hit the button. The tags look something like: my_submit property=formAction value=delete label=Delete this record/ my_submit property=formAction value=save label=Save changes/ my_submit property=formAction value=copy label=Copy this record/ etc A single action object can then use the value of formAction to decide what to do in each case. This has the side-effect of reducing the number of Action classes needed. However, the tags generate javascript and I wasn't sure if this fitted the struts philosophy; so I haven't submitted the code changes. But if anyone was interested I could make it available. Joe Faith Runtime Collective, Ltd T: (+44) 01273 234294 Erik Hatcher wrote: As promised earlier today, here is my contribution to the multiple html:submit button saga (Ted, time to update your FAQ! :)
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Most of us would not rely *solely* on Javascript for validation, since it can be turned off, and therefor endanger your application. But requiring it to handle multiple buttons is a different matter, so long as the default formAction did nothing harmful if Javascript were turned off. The ValidatorForm in the contrib folder generates *lots* of Javascript. The html:form tag also generates a Javascript to move the focus, as do some others. So, I don't see anything wrong with a tag that generated Javascript for setting a property. Heck, I'm doing by hand myself ;-) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ Joe Faith wrote: We have also implemented a multiple submit button system; but in our case we wrote a custom tag that generates javascript that sets a property to a specified value and submits the form when you hit the button. The tags look something like: my_submit property=formAction value=delete label=Delete this record/ my_submit property=formAction value=save label=Save changes/ my_submit property=formAction value=copy label=Copy this record/ etc A single action object can then use the value of formAction to decide what to do in each case. This has the side-effect of reducing the number of Action classes needed. However, the tags generate javascript and I wasn't sure if this fitted the struts philosophy; so I haven't submitted the code changes. But if anyone was interested I could make it available. Joe Faith Runtime Collective, Ltd T: (+44) 01273 234294 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Hi Joe, I would certainly be interested in your code for this tag, as I have decided to make javascript a prerequisite for my project. Regards Andy - Original Message - From: Joe Faith [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, November 15, 2001 10:08 AM Subject: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons We have also implemented a multiple submit button system; but in our case we wrote a custom tag that generates javascript that sets a property to a specified value and submits the form when you hit the button. The tags look something like: my_submit property=formAction value=delete label=Delete this record/ my_submit property=formAction value=save label=Save changes/ my_submit property=formAction value=copy label=Copy this record/ etc A single action object can then use the value of formAction to decide what to do in each case. This has the side-effect of reducing the number of Action classes needed. However, the tags generate javascript and I wasn't sure if this fitted the struts philosophy; so I haven't submitted the code changes. But if anyone was interested I could make it available. Joe Faith Runtime Collective, Ltd T: (+44) 01273 234294 Erik Hatcher wrote: As promised earlier today, here is my contribution to the multiple html:submit button saga (Ted, time to update your FAQ! :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Antwort: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
Yet another approach would be to use an image tag:
html:image page=/images/lock.gif property=lock /
html:image page=/images/unlock.gif property=unlock /
html:image page=/images/delete.gif property=delete /
and check parameter in action:
if (request.getParameter(lock.x) != null) {
// decide what to do
// 1) either return mapping.findForward(lock);
// with forward name=lock path=/lock.do/ declared in struts-config
// (this results in performace drawback, but makes design more flexible)
// 2) just simply call an appropriate method
}
else if (request.getParameter(unlock.x) != null){
// decide what to do
}
else if (request.getParameter(delete.x) != null) {
// decide what to do
}
Of cource it could be optimized with map and base dispatcher class.
Dmitri Valdin
Datum: 15.11.2001 11:41
An:Struts Developers List [EMAIL PROTECTED]
Antwort an:Struts Developers List [EMAIL PROTECTED]
Betreff: Re: [SUBMIT] LookupDispatchAction - how to handle multiple html:submit
buttons
Nachrichtentext:
Most of us would not rely *solely* on Javascript for validation, since
it can be turned off, and therefor endanger your application. But
requiring it to handle multiple buttons is a different matter, so long
as the default formAction did nothing harmful if Javascript were turned
off.
The ValidatorForm in the contrib folder generates *lots* of Javascript.
The html:form tag also generates a Javascript to move the focus, as do
some others. So, I don't see anything wrong with a tag that generated
Javascript for setting a property. Heck, I'm doing by hand myself ;-)
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
Joe Faith wrote:
We have also implemented a multiple submit button system; but in our
case we wrote a custom tag that generates javascript that sets a property
to a specified value and submits the form when you hit the button.
The tags look something like:
my_submit property=formAction value=delete label=Delete this
record/
my_submit property=formAction value=save label=Save changes/
my_submit property=formAction value=copy label=Copy this record/
etc
A single action object can then use the value of formAction to decide what to
do in each case.
This has the side-effect of reducing the number of Action classes needed.
However, the tags generate javascript and I wasn't sure if this fitted the
struts philosophy; so I
haven't submitted the code changes. But if anyone was interested I could make
it available.
Joe Faith
Runtime Collective, Ltd
T: (+44) 01273 234294
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn
Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[SUBMIT] LookupDispatchAction - how to handle multiple html:submit buttons
As promised earlier today, here is my contribution to the multiple
html:submit button saga (Ted, time to update your FAQ! :)
Here is a breakdown of how to use it:
struts-config.xml segment, note the parameter=action
action path=/test
type=edu.darden.TestAction
name=TestForm
scope=request
input=/test.jsp
validate=true
parameter=action
forward name=success path=/results.jsp/
/action
ApplicationResources.properties segment:
button.add=Add Record
button.delete=Delete Record
TestAction.java (extends LookupDispatchAction) segment, the map is keyed by
ApplicationResources.properties
keys, and the value is the method name you want called (with the same
signature as Action.perform):
protected Map getKeyMethodMap(ActionMapping mapping,
ActionForm form,
HttpServletRequest
request) {
Map map = new HashMap();
map.put(button.add, add);
map.put(button.delete, delete);
return map;
}
public ActionForward add(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
System.out.println( ADD!);
return null;
}
public ActionForward delete(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
System.out.println( DELETE!);
return null;
}
And finally the JSP code segment:
html:form action=/test
html:submit property=action
bean:message key=button.add/
/html:submit
html:submit property=action
bean:message key=button.delete/
/html:submit
/html:form
I recommend the above usage in most cases to cut down on the 'if' statements
and making each unique action clearly defined in separate methods.
But, if there is ever a need to be more general with it, I have provided in
my base class the flexibility to handle dispatching to a single method for
all keys, providing the key to the method. I can only see this being useful
if you have a whole bunch of buttons and there is little difference in the
actions they perform and you only need to do minor logic based on the key.
Here is an example of this, note that if you implement getKeys (and do not
return null) that getKeyMethodMap is not used, so in all but the most crazy
cases would you ever implement both getKeys and getKeyMethodMap. I provided
the mapping, form, and request to these methods just in case someone wanted
to do some dynamic crazy stuff with the array or Map returned from these
methods, but I don't see those parameters being used in most cases.
protected String[] getKeys(ActionMapping mapping,
ActionForm form,
HttpServletRequest request) {
return new String[] {button.add, button.delete };
}
protected ActionForward perform(String key,
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
System.out.println( key = + key);
return null;
}
I am out of town for a long weekend tomorrow, so I wanted to get this done
today and get it out to struts-dev for feedback. I plan on providing Cactus
or Deryl's mock test cases for this (but if anyone wants to beat me to
generating those, feel free!) - for this I really just want to verify that
the correct methods get dispatched with the proper key and that error
handling is dealt with appropriately so Cactus isn't necessary. I based it
loosely off of DispatchAction. It would be nice if my invokeMethod was
actually pushed up to DispatchAction to avoid duplicate code and
DispatchAction refactored to use this helper method.
I believe I might have made this class a little too feature-rich and perhaps
it should be broken into two base classes - one to dispatch via reflection
to a Map specified mapping between key and method, and another to do the
dispatching to an enhanced perform method taking the key. With two separate
base classes the getKeys, getKeyMethodMap and perform could all be made
abstract and remove some likely usage confusion.
My Javadoc comments need some work to encompass both ways of using my base
class, but both methods are documented in this message for now.
I welcome feedback and suggestions on this.
Erik
