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: 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]
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]
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]
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]
