OK, I'm back. Now where were we...
What you're suggesting is this?
<action path="/myAction"
type="o.a.s.actions.SuccessAction">
<forward name="success" path="/myPage.jsp">
</action>
<action path="/myOtherAction"
type="o.a.s.actions.SuccessAction"
parameter="oops">
<forward name="oops" path="/myPage.jsp">
</action>
I honestly don't see the value in the second method. You've just added a
parameter to tell the action which forward to select when there is only one
possible choice. You've also got two actions which do exactly the same
thing, but are configured differently.
My concern is that adding the parameter makes the use of the action a little
less of a no-brainer (sometimes a *little* more complexity is all it takes).
I would be grateful if you could give an illustration of an example where
"success" couldn't be used. Most other actions can be identified as having a
success or fail outcome (or something in between). To my mind this is an
action where the only possible outcome is success, so I can't see why the
name would cause you so much trouble. Even if you're forwarding to an error
page, the *action* is still successful.
Please reconsider whether having the flexibility of adding the parameter is
really necessary. I think that in the vast majority of cases it isn't and
for the minority a custom action would be an option.
However, if you're *really* set on having the parameter option then let's go
with SuccessAction, with the forward name being supplied by the parameter
and defaulting to "success" if none is supplied. Ok?
But, only if you really, really, really insist ;-)
Steve
> -----Original Message-----
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: August 5, 2003 6:52 AM
> To: Struts Developers List
> Subject: RE: Addition of two new actions
>
>
> --- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> > This is not a general purpose action.
>
> IMO, limited use inflexible actions don't belong in the Struts distro. We
> should provide common actions to ease development but they should be
> configurable to the user's needs.
>
> > It is intended to do just one
> > thing
> > and that's forward the request to one place.
>
> My suggestion doesn't change that.
>
> > There is deliberately no
> > flexibility in the action. The flexibility comes from being able to use
> > an
> > ActionFoward definition.
> >
> > We wouldn't be dictating anything because you always have the option of
> > creating a custom action. However, if you want to do this right now then
> > Struts *requires* that you create your own action.
> >
> > To enable naming the foward via parameter would IMHO be generalising at
> > the
> > expense of usability.
>
> Please elaborate on this. I don't see any drawbacks to allowing people
> the freedom of defining what forward the action points to. Hardcoding a
> forward name with no option to configure it forces people into using
> semantics that may not be appropriate in their use case.
>
> >
> > SuccessAction already seems to be a common idiom and I think this would
> > just
> > reflect what many people are already doing and make it just a little bit
> > easier.
>
> I can't speak for anyone but me but all of my actions call the business
> layer and forward to a success forward (not necessarily named "success"
> though). I use <action forward=""> when all I need is to front a JSP with
> an Action. The only improvement that SuccessAction provides is allowing
> you to declare the forward with the more powerful <forward> element and
> not having to write an action that merely forwards to it. Why must that
> forward be arbitrarily named "success"?
>
> David
>
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: David Graham [mailto:[EMAIL PROTECTED]
> > > Sent: August 4, 2003 3:06 PM
> > > To: Struts Developers List
> > > Subject: RE: Addition of two new actions
> > >
> > >
> > > --- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> > > > I haven't suggested another way of specifying a forward. Just
> > providing
> > > > an
> > > > action that uses the existing, most common way of doing so.
> > > >
> > > > I wouldn't want to add contextRelative attribute to <action>
> > because:
> > > > - it doesn't relate to the ActionMapping, but to the ActionForward
> > > > - having the same attribute specified in two places would cause
> > > > confusion
> > > >
> > > > Although, SuccessAction is a trivial action, it does fill a gap that
> > is
> > > > not
> > > > fully met by either <action forward=""> or ForwardAction. How would
> > > > adding
> > > > it be bad for Struts?
> > >
> > > One thing that really bothers me about this action is that it forces
> > the
> > > user to use "success" as the forward name. This isn't appropriate in
> > > every use case and Struts shouldn't dictate this type of thing. What
> > > about specifying the forward name in the "parameter" attribute? Maybe
> > > even say that "success" is the default name if parameter isn't
> > provided?
> > > That gives you an action that just forwards to some ActionForward
> > without
> > > demanding that the forward be named "success". This would also
> > require a
> > > rename of SuccessAction to something more suitable (maybe
> > > ForwardingAction?).
> > >
> > > David
> > >
> > > >
> > > > Steve
> > > >
> > > > > -----Original Message-----
> > > > > From: David Graham [mailto:[EMAIL PROTECTED]
> > > > > Sent: August 4, 2003 1:32 PM
> > > > > To: Struts Developers List
> > > > > Subject: RE: Addition of two new actions
> > > > >
> > > > >
> > > > > --- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> > > > > > You're right <action forward=""> is module relative (despite
> > what it
> > > > > > says in
> > > > > > the Javadoc). However, I don't see how it can used with a
> > context
> > > > > > relative
> > > > > > path.
> > > > >
> > > > > Maybe it needs a contextRelative attribute.
> > > > >
> > > > > >
> > > > > > There is no contextRelative attribute on the action config so
> > you
> > > > don't
> > > > > > get
> > > > > > to choose (or change) how your forward works.
> > > > >
> > > > > Maybe there should be. Isn't enhancing existing functionality to
> > make
> > > > it
> > > > > better simpler than adding yet another way of specifying a
> > forward?
> > > > >
> > > > > >
> > > > > > Of the three ways of defining forwards that you identified only
> > one,
> > > > > > <forward>, works flexibly with modules and that's the one that
> > we
> > > > don't
> > > > > > ship
> > > > > > an action for with Struts.
> > > > > >
> > > > > > SuccessAction works flexibly with modules, it's tool friendly,
> > it's
> > > > > > simple
> > > > > > to understand and its configuration is consistent with almost
> > all
> > > > other
> > > > > > actions.
> > > > >
> > > > > It may be simple to understand when considered alone but in the
> > > > context of
> > > > > the variety of other methods of defining forwards it makes things
> > more
> > > > > complex. Maybe we need to revisit the concept of forwards and/or
> > how
> > > > we
> > > > > define them.
> > > > >
> > > > > David
> > > > >
> > > > >
> > > > > >
> > > > > > Steve
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > > http://sitebuilder.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
