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 "/page&method=X" becomes "/a1b2c3d4e5.psc", you've
just made the security more obscure. If someone figures out your encoding,
they can s
Paul Speed wrote:
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 co
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
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 coul
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 allowin
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
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 cr
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-mea
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 cl
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
> parame
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
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
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
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
-
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
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 w
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 "belo
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
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
o
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 MappingDispatchAct
[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 ess
ge-
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 d
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 ActionSer
Comments inline - don't usually do that
- Original Message -
From: "Michael McGrady" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 1:54 AM
Subject: Re: DispatchAction
> Niall Pemberton 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 i
<[EMAIL PROTECTED]>
Sent: Friday, September 17, 2004 12:40 AM
Subject: 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 A
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
Michael McGrady wrote:
Hubert Rabago wrote:
Yes, that's the general idea. Like I said, I haven't looked at it
closely yet to see if it's doable for the existing *DispatchAction
flavors. *If* it can be done (some methods just can't be moed that
easily), then the functionality becomes available to
Tom Drake wrote:
It appears that what we have are different strategies for determining the
method name. Given that, wouldn't it make more sense to have a single
version of DispatchAction (perhaps called StrategyDispatchAction) which
relies on a named strategy class to resolve the method name
That w
Hubert Rabago wrote:
Yes, that's the general idea. Like I said, I haven't looked at it
closely yet to see if it's doable for the existing *DispatchAction
flavors. *If* it can be done (some methods just can't be moed that
easily), then the functionality becomes available to Action subclasses
that
nspecified() if name is null
return parameter;
}
}
-Original Message-
From: Michael McGrady [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 16, 2004 3:08 PM
To: Struts Developers List
Subject: Re: DispatchAction
Hubert Rabago wrote:
>public ActionForward execute(
Yes, that's the general idea. Like I said, I haven't looked at it
closely yet to see if it's doable for the existing *DispatchAction
flavors. *If* it can be done (some methods just can't be moed that
easily), then the functionality becomes available to Action subclasses
that don't extend one of t
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
ers 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 refact
Hubert Rabago wrote:
What I had in mind was moving the "find which Action method to call
then call it" logic to a utility class, so that if I needed that
functionality, I could use it without having to inherit DispatchAction
or one of its subclasses. This way, I wouldn't have to choose between
hav
Hubert Rabago wrote:
I haven't had a chance to look into the latest DispatchAction yet, but
if it's already in there, I wouldn't be surprised.
This cannot be. I am not sure you two see what this does. I know you
two are sharp cookies, but you might be looking at the results and
seeing they a
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 differen
d 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: Di
Niall Pemberton wrote:
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
No, that cannot be true, Niall, because eveyrone's code would break.
Michael
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
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, Se
I probably should have noted that SimpleDispatchAction is a complete
substitute for and works in all cases for whatever we do with
DispatchAction, LookupDispatchAction, and MappingDispatchAction. That
might be another reason for making it the superclass, if you really want
to connect them.
Ma
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 n
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 hier
44 matches
Mail list logo
