Yes, I would love to add image button handling capability to
LookupDispatchAction. It would be nice to make it generic so a designer can
switch between using text or graphical submit buttons without the Action
needing any modification at all. Any ideas?
There are two scenarios as I see it - one where the action parameter name
remains constant and the value varies between buttons (and the button text
is stored in ApplicationResources), and one in which the action parameter
name changes and that is used to key dispatching. I'm not sure both
situations can be combined into a single handler, or that it makes sense to
since a designer shouldn't be switching between these two different modes
without the code having to change but switching between text and graphical
buttons should be allowed without code change. Do folks agree with these
scenarios?
Perhaps there can be four new "dispatch" base classes:
* Single action parameter name - dispatch to a single method passing the
key from ApplicationResources.
* Single action parameter name - dispatch to programmer-defined methods
using the key from ApplicationResources as a map to the method name where
the method has the same signature as Action.perform (although it might be
nice to add the 'key' to the method signature also).
* Differing action parameter names (action determined by existence of
parameter, not value) - dispatch to single method passing the action
parameter name as the 'key'. It should probably also provide the x/y
coordinates to the dispatch method. Should it implicitly append ".x" if
the raw action name is not available in order to determine which action was
selected? Or how should it flexibly handle text and graphical buttons?
* Differing action parameter names (again, action determined by
existence of parameter, not value) - dispatch to programmer-defined methods
using the parameter name and use parameter name directly as method name as
DispatchAction does. Same questions apply as the previous item.
This would provide a lot of added flexibility for developers, and separate
controller from view much better than current capabilities. The
LookupDispatchAction I posted provided the first two capabilities together,
but I can't see both needed at once so I'd like to split it to allow clearer
usage and avoid documentation confusion.
What do others think about these proposed additions? Would they meet
everyone's needs?
Thanks,
Erik
----- Original Message -----
From: "Dimitri Valdin" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, November 15, 2001 3:03 AM
Subject: 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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
