t;[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
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
> 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 so
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
- 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
Erik Hatcher wrote:
> No its not. What if I want to map several keys to a single method? That is
> perfectly legitimate use-case where only one minor thing needs to change
> between different key values.
Personally, I would then consider the keys a form of input and make them
part of the Action
From: "Ted Husted" <[EMAIL PROTECTED]>
> 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.
No its not. What if I want to map several keys to a single method?
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 extensi
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
> > - 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"
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
- 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.
Erik Hatcher wrote:
> 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.
It's starting to couple what we want to call the buttons w
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 t
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/s
Erik Hatcher wrote:
> 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 tak
quot;.equals(key)), but I definitely agree that its useful to have a
more generic dispatch just passing the key.
Thats all for now!
Erik
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Sa
> 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, w
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
lo
>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 viab
> 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, a
>*whew* - much better! :)
glad about that :-)
>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.
well, but now, in case of using DispatchAcion this footprint is really small,
I would say, that
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: R
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:
Dmitri Valdin
--
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Inf
> That was the reason, why I wrote that application resources also play an
> important role in your design.
Without a doubt - by 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, b
>For images I would put the image name in ApplicationResource.properties and
>use - 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 t
> 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 Applicati
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 image
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 contr
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 s
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 fo
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 generate
D]>
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 button
ber 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 subm
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 Validat
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:
etc
A single action object can then use
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"
ApplicationResources.properties segment:
button.ad
35 matches
Mail list logo
