You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Steve Raeburn <sr...@apache.org> on 2003/08/08 23:37:58 UTC
SuccessAction (was RE: Addition of two new actions)
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:grahamdavid1980@yahoo.com]
> Sent: August 5, 2003 6:52 AM
> To: Struts Developers List
> Subject: RE: Addition of two new actions
>
>
> --- Steve Raeburn <sr...@apache.org> 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:grahamdavid1980@yahoo.com]
> > > Sent: August 4, 2003 3:06 PM
> > > To: Struts Developers List
> > > Subject: RE: Addition of two new actions
> > >
> > >
> > > --- Steve Raeburn <sr...@apache.org> 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:grahamdavid1980@yahoo.com]
> > > > > Sent: August 4, 2003 1:32 PM
> > > > > To: Struts Developers List
> > > > > Subject: RE: Addition of two new actions
> > > > >
> > > > >
> > > > > --- Steve Raeburn <sr...@apache.org> 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: struts-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! SiteBuilder - Free, easy-to-use web site design software
> > > http://sitebuilder.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by Leonardo Quijano Vincenzi <lq...@hotpop.com>.
Hi
Some time ago I submitted a couple of refactorings to the
DispatchAction/LookupDispatchAction classes. Since there was a recent
discussion on these actions, I was wondering if that patch was going to
be submitted for 1.2. Is there anything else I need to do?
the patch is here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=18002
Thanks
Leonardo
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 11 Aug 2003, Ted Husted wrote:
> Since, I'm lead to understand Craig finds "http" hard to say when he
> gives talks =:)
>
Ah, you've heard me trip over that one? :-).
I actually like "web" better than "http" for a different reason -- it
doesn't presume the "one true way" protocol will be around forever.
While talking about contexts and layers, there's actually room for a
controller layer below the HTTP layer as well, on top of which you can
build the web layer and then the app layer. The general pattern is also
useful in business logic as well.
That idea, and some of your earlier thoughts, were part of the inspiration
for commons-chain -- which I've been noodling on for about six months but
never had time to get finished and polished enough to post until this last
weekend.
> -Ted.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> David Graham wrote:
> > No, I was thinking Actions would be passed an ActionContext in their
> > execute() method similar to how Servlets know about a ServletContext.
> The
> > ActionContext would contain the HttpServletRequest, form bean, etc.
> and
> > would serve to keep the API stable while allowing flexibility in what
> the
> > ActionContext actually contained.
>
> Perhaps it's time for a Commons Context foundation class. Tiles uses a
> Context, Velocity uses a Context, the Commons-Chain sandbox package uses
>
> a Context, Struts wants to use a Context, and I'm sure that there are
> others.
>
> Ideally, we might want to be able to pass a Context between Struts and
> the business layer as well as other packages like Tiles and Velocity. So
>
> it might be helpful if they could be implementations of the same
> underlying interface.
>
> Perhaps we could squeeze it into Resources, since, in practice, messages
>
> are definitely something you would be attaching to a Context.
>
> =:0) I just don't want Geir coming along in a few months and pointing
> out how many Context implementations we have in Jakarta now =:0)
I'm not sure that Context is a reusable idea. The ActionContext is likely
to have very different attributes than a VelocityContext (or whatever they
call it). For example, Servlet has ServletConfig and Portlet has
PortletConfig but that doesn't mean they could both be crammed into
OneBigConfig :-).
David
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by Ted Husted <hu...@apache.org>.
David Graham wrote:
> No, I was thinking Actions would be passed an ActionContext in their
> execute() method similar to how Servlets know about a ServletContext. The
> ActionContext would contain the HttpServletRequest, form bean, etc. and
> would serve to keep the API stable while allowing flexibility in what the
> ActionContext actually contained.
Perhaps it's time for a Commons Context foundation class. Tiles uses a
Context, Velocity uses a Context, the Commons-Chain sandbox package uses
a Context, Struts wants to use a Context, and I'm sure that there are
others.
Ideally, we might want to be able to pass a Context between Struts and
the business layer as well as other packages like Tiles and Velocity. So
it might be helpful if they could be implementations of the same
underlying interface.
Perhaps we could squeeze it into Resources, since, in practice, messages
are definitely something you would be attaching to a Context.
=:0) I just don't want Geir coming along in a few months and pointing
out how many Context implementations we have in Jakarta now =:0)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> My only concern would be using the term "context" to imply more than one
>
> object.
>
> IMHO, there should be a functional non-httpd framework below Struts,
> that would provide things like a Context Object, which would be a
> generic version of the HttpRequest. At the Stuts level, you could then
> have available to you signatures that used a Context or a HttpContext.
>
> In the future, we should be able to write pure business Actions that
> don't use http semantics, and only use the http version when we
> absolutely need to. In practice, most of us rarely use the http services
>
> of the HttpRequest, and the same Actions could be coded using a generic
> Context (that might be chained to the HttpRequest, as is done with the
> Velocity Tools).
>
> [We started along this way with duel Action classes, but I've never even
>
> tried to use the non-http one.]
>
> So, if we're talking about the ActionContext interface being an
> abstraction of the Action class, I'd like to search for another name.
No, I was thinking Actions would be passed an ActionContext in their
execute() method similar to how Servlets know about a ServletContext. The
ActionContext would contain the HttpServletRequest, form bean, etc. and
would serve to keep the API stable while allowing flexibility in what the
ActionContext actually contained.
David
> My
>
> suggestion for an Action class interface would be
>
> Action <- HttpDispatcher.
>
> As for the other core classes, I would suggest
>
> ActionForward <- HttpResource
>
> ActionMapping <- HttpCommand
>
> or, if you prefer,
>
> Action <- WebDispatcher
>
> ActionForward <- WebResource
>
> ActionMapping <- WebCommand
>
> Since, I'm lead to understand Craig finds "http" hard to say when he
> gives talks =:)
>
> -Ted.
>
>
> David Graham wrote:
>
> > --- Joe Germuska <Jo...@Germuska.com> wrote:
> >
> >>Just a little "me-too" here, but I think both Ted and David have good
> >>points. Ted's approach to adding a controller to the ActionForward
> >>is a relatively small change to the infrastructure that can offer a
> >>lot of gain. And I've been interested in seeing some kind of
> >>ActionContext class for quite a while now.
> >
> >
> > I chose my words carefully when I said "ActionContext interface". I
> > *think* we can all agree that if we added this it should be an
> interface
> > :-).
> >
> > David
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by Ted Husted <hu...@apache.org>.
My only concern would be using the term "context" to imply more than one
object.
IMHO, there should be a functional non-httpd framework below Struts,
that would provide things like a Context Object, which would be a
generic version of the HttpRequest. At the Stuts level, you could then
have available to you signatures that used a Context or a HttpContext.
In the future, we should be able to write pure business Actions that
don't use http semantics, and only use the http version when we
absolutely need to. In practice, most of us rarely use the http services
of the HttpRequest, and the same Actions could be coded using a generic
Context (that might be chained to the HttpRequest, as is done with the
Velocity Tools).
[We started along this way with duel Action classes, but I've never even
tried to use the non-http one.]
So, if we're talking about the ActionContext interface being an
abstraction of the Action class, I'd like to search for another name. My
suggestion for an Action class interface would be
Action <- HttpDispatcher.
As for the other core classes, I would suggest
ActionForward <- HttpResource
ActionMapping <- HttpCommand
or, if you prefer,
Action <- WebDispatcher
ActionForward <- WebResource
ActionMapping <- WebCommand
Since, I'm lead to understand Craig finds "http" hard to say when he
gives talks =:)
-Ted.
David Graham wrote:
> --- Joe Germuska <Jo...@Germuska.com> wrote:
>
>>Just a little "me-too" here, but I think both Ted and David have good
>>points. Ted's approach to adding a controller to the ActionForward
>>is a relatively small change to the infrastructure that can offer a
>>lot of gain. And I've been interested in seeing some kind of
>>ActionContext class for quite a while now.
>
>
> I chose my words carefully when I said "ActionContext interface". I
> *think* we can all agree that if we added this it should be an interface
> :-).
>
> David
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by David Graham <gr...@yahoo.com>.
--- Joe Germuska <Jo...@Germuska.com> wrote:
> Just a little "me-too" here, but I think both Ted and David have good
> points. Ted's approach to adding a controller to the ActionForward
> is a relatively small change to the infrastructure that can offer a
> lot of gain. And I've been interested in seeing some kind of
> ActionContext class for quite a while now.
I chose my words carefully when I said "ActionContext interface". I
*think* we can all agree that if we added this it should be an interface
:-).
David
>
> Joe
>
>
> At 6:47 -0700 8/11/03, David Graham wrote:
> >--- Ted Husted <hu...@apache.org> wrote:
> >> David Graham wrote:
> >> > What I think we're seeing here
> >> > is that we've outgrown our ActionForward declarations and need
> some
> >> new
> >> > ones. I'm fine with adding a SuccessAction but would really like
> to
> >> see
> >> > us discuss future possibilities in this area.
> >>
> >> This may not be what you meant, but I've been thinking that
> >> ActionForward could use a class extension point, same as
> ActionMapping.
> >>
> >> The idea would be to give ActionForward a type property for a Java
> >> class. If the property is specified, instead of just taking the path
> as
> >> it stands, the Controller would call a "prepare" method on the
> class,
> >> passing it the ActionForward, ActionForm, HttpRequest, and
> HttpResponse.
> >
> >This may be a good time to add an ActionContext interface instead of
> >passing all these individual pieces. This would also slightly remove
> the
> >dependence on Servlet to allow us more flexibility when we look at the
> >Portlet API.
> >
> >>
> >> The prepare method would return a String that the Controller would
> use
> >> for the path.
> >>
> >> This allows the ActionForward to act as a Page Controller for the
> path.
> >> If the particular page referenced by the path needs any special
> "chrome"
> >>
> >> the Page Controller can set that up. Or, if the path needs to be
> >> adjusted for Locale or device (PDA, browser, et al), then the Page
> >> Controller could adjust the path before returning it.
> >>
> >> If it were a virtual page, like an dynamic image, merge file, or
> PDF,
> >> the Page class could also render the Response, rather than have the
> >> Action do it.
> >>
> >> Right now, the Action is doing double duty. It first acts as a
> >> Dispatcher that acquires business resources and selects the logical
> >> view. But, in real life, many pages often need special runtime
> resources
> >>
> >> of their own. So, the Action also serves as a Page Controller for
> the
> >> page it selects. Many of us consider that a mixing of concerns, and
> so
> >> we start to use some Actions as Dispatchers and others as Page
> >> Controllers. Tiles also fills this gap and is essentially a hybrid
> of a
> >> Compositive View and a Page Controller framework.
> >>
> >> I'm thinking that, architecturally, the ActionForward represents
> some
> >> resource available to the application, of any type, that can be
> reached
> >> by the application's protocol. In an http environment, it's the job
> of a
> >>
> >> Resource object to provide a URI that the Controller can use the
> reach
> >> the actual resource. (And, in another environment, perhaps the path
> >> would not be a URI.)
> >>
> >> The Action, in its purest form, represents a Dispatcher. It's the
> job of
> >>
> >> a Dispatcher to select which (logical) Resource will handle the
> >> response. When we talk about selecting between "success", "failure",
> or
> >> "glockenspiel", we're talking about dispatching.
> >>
> >> But, in real life, we often can't just dispatch to a page. The page
> >> needs certain resources to render, often to fill UI controls like
> select
> >>
> >> lists.
> >>
> >> Ideally, I believe another class, specified by the ActionForward,
> should
> >>
> >> be responsible for setting up any "chrome" a particular page may
> need.
> >> It's the one that knows where the page is (via the path property),
> and
> >> so it's the one that should be privy to these details.
> >>
> >> What would start to happen here, I think, is that people will put
> into
> >> the new class the code that now encourages them to "chain"
> >> some Actions. By providing a separation of concern between "choosing
> the
> >> Resource" and "preparing the context for the Resource", it becomes
> >> easier for people to Do The Right Thing.
> >
> >I've had similar composition problems and agree that a separation makes
> >sense. Tiles Controllers can be used to setup page data but that
> doesn't
> >always work (especially if you're not using Tiles :-) so I end up
> chaining
> >actions. None of the action chaining is due to bus. logic as that's
> >properly factored into a Service layer; it has to do purely with
> setting
> >up page data.
> >
> >Tiles Controllers are one of the major reasons I use Tiles and I think
> >it's appropriate to move that concept into the Struts core.
> >
> >David
> >
> >>
> >> The "gotcha" is that, to do its job, the ActionForward type may also
> >> need to interact with the business layer. It doesn't seem right that
> the
> >>
> >> Page Controller should try to branch to another page, like an Action
> >> might, if there's an error. But the declarative exception handling
> might
> >>
> >> be able to step in here.
> >>
> >> -Ted.
> >>
> >> --
> >> Ted Husted,
> >> Junit in Action - <http://www.manning.com/massol/>,
> >> Struts in Action - <http://husted.com/struts/book.html>,
> >> JSP Site Design -
> >> <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >>
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >Yahoo! SiteBuilder - Free, easy-to-use web site design software
> >http://sitebuilder.yahoo.com
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
> --
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "If nature worked that way, the universe would crash all the time."
> --Jaron Lanier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by Joe Germuska <Jo...@Germuska.com>.
Just a little "me-too" here, but I think both Ted and David have good
points. Ted's approach to adding a controller to the ActionForward
is a relatively small change to the infrastructure that can offer a
lot of gain. And I've been interested in seeing some kind of
ActionContext class for quite a while now.
Joe
At 6:47 -0700 8/11/03, David Graham wrote:
>--- Ted Husted <hu...@apache.org> wrote:
>> David Graham wrote:
>> > What I think we're seeing here
>> > is that we've outgrown our ActionForward declarations and need some
>> new
>> > ones. I'm fine with adding a SuccessAction but would really like to
>> see
>> > us discuss future possibilities in this area.
>>
>> This may not be what you meant, but I've been thinking that
>> ActionForward could use a class extension point, same as ActionMapping.
>>
>> The idea would be to give ActionForward a type property for a Java
>> class. If the property is specified, instead of just taking the path as
>> it stands, the Controller would call a "prepare" method on the class,
>> passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse.
>
>This may be a good time to add an ActionContext interface instead of
>passing all these individual pieces. This would also slightly remove the
>dependence on Servlet to allow us more flexibility when we look at the
>Portlet API.
>
>>
>> The prepare method would return a String that the Controller would use
>> for the path.
>>
>> This allows the ActionForward to act as a Page Controller for the path.
>> If the particular page referenced by the path needs any special "chrome"
>>
>> the Page Controller can set that up. Or, if the path needs to be
>> adjusted for Locale or device (PDA, browser, et al), then the Page
>> Controller could adjust the path before returning it.
>>
>> If it were a virtual page, like an dynamic image, merge file, or PDF,
>> the Page class could also render the Response, rather than have the
>> Action do it.
>>
>> Right now, the Action is doing double duty. It first acts as a
>> Dispatcher that acquires business resources and selects the logical
>> view. But, in real life, many pages often need special runtime resources
>>
>> of their own. So, the Action also serves as a Page Controller for the
>> page it selects. Many of us consider that a mixing of concerns, and so
>> we start to use some Actions as Dispatchers and others as Page
>> Controllers. Tiles also fills this gap and is essentially a hybrid of a
>> Compositive View and a Page Controller framework.
>>
>> I'm thinking that, architecturally, the ActionForward represents some
>> resource available to the application, of any type, that can be reached
>> by the application's protocol. In an http environment, it's the job of a
>>
>> Resource object to provide a URI that the Controller can use the reach
>> the actual resource. (And, in another environment, perhaps the path
>> would not be a URI.)
>>
>> The Action, in its purest form, represents a Dispatcher. It's the job of
>>
>> a Dispatcher to select which (logical) Resource will handle the
>> response. When we talk about selecting between "success", "failure", or
>> "glockenspiel", we're talking about dispatching.
>>
>> But, in real life, we often can't just dispatch to a page. The page
>> needs certain resources to render, often to fill UI controls like select
>>
>> lists.
>>
>> Ideally, I believe another class, specified by the ActionForward, should
>>
>> be responsible for setting up any "chrome" a particular page may need.
>> It's the one that knows where the page is (via the path property), and
>> so it's the one that should be privy to these details.
>>
>> What would start to happen here, I think, is that people will put into
>> the new class the code that now encourages them to "chain"
>> some Actions. By providing a separation of concern between "choosing the
>> Resource" and "preparing the context for the Resource", it becomes
>> easier for people to Do The Right Thing.
>
>I've had similar composition problems and agree that a separation makes
>sense. Tiles Controllers can be used to setup page data but that doesn't
>always work (especially if you're not using Tiles :-) so I end up chaining
>actions. None of the action chaining is due to bus. logic as that's
>properly factored into a Service layer; it has to do purely with setting
>up page data.
>
>Tiles Controllers are one of the major reasons I use Tiles and I think
>it's appropriate to move that concept into the Struts core.
>
>David
>
>>
>> The "gotcha" is that, to do its job, the ActionForward type may also
>> need to interact with the business layer. It doesn't seem right that the
>>
>> Page Controller should try to branch to another page, like an Action
>> might, if there's an error. But the declarative exception handling might
>>
>> be able to step in here.
>>
>> -Ted.
>>
>> --
>> Ted Husted,
>> Junit in Action - <http://www.manning.com/massol/>,
>> Struts in Action - <http://husted.com/struts/book.html>,
>> JSP Site Design -
>> <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free, easy-to-use web site design software
>http://sitebuilder.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: ActionForwards, et al (was SuccessAction)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 11 Aug 2003, Mike Jasnowski wrote:
> Date: Mon, 11 Aug 2003 09:50:29 -0400
> From: Mike Jasnowski <mj...@bea.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>,
> dgraham@apache.org
> Subject: RE: ActionForwards, et al (was SuccessAction)
>
> >This may be a good time to add an ActionContext interface instead of
> >passing all these individual pieces. This would also slightly remove the
> >dependence on Servlet to allow us more flexibility when we look at the
> >portlet API.
>
> As an outside observer I would like to see something like this added. We've
> already added something like you
> describe to our application.
>
You'll also note that commons-chain (basis for the decomposable request
processor proposal) does exactly this, with the added twist that it lets
you specialize the Context implementation with typesafe property accessors
if you want to, or use generic attributes otherwise.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: ActionForwards, et al (was SuccessAction)
Posted by Mike Jasnowski <mj...@bea.com>.
>This may be a good time to add an ActionContext interface instead of
>passing all these individual pieces. This would also slightly remove the
>dependence on Servlet to allow us more flexibility when we look at the
>portlet API.
As an outside observer I would like to see something like this added. We've
already added something like you
describe to our application.
-----Original Message-----
From: David Graham [mailto:grahamdavid1980@yahoo.com]
Sent: Monday, August 11, 2003 9:47 AM
To: Struts Developers List
Subject: Re: ActionForwards, et al (was SuccessAction)
--- Ted Husted <hu...@apache.org> wrote:
> David Graham wrote:
> > What I think we're seeing here
> > is that we've outgrown our ActionForward declarations and need some
> new
> > ones. I'm fine with adding a SuccessAction but would really like to
> see
> > us discuss future possibilities in this area.
>
> This may not be what you meant, but I've been thinking that
> ActionForward could use a class extension point, same as ActionMapping.
>
> The idea would be to give ActionForward a type property for a Java
> class. If the property is specified, instead of just taking the path as
> it stands, the Controller would call a "prepare" method on the class,
> passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse.
This may be a good time to add an ActionContext interface instead of
passing all these individual pieces. This would also slightly remove the
dependence on Servlet to allow us more flexibility when we look at the
Portlet API.
>
> The prepare method would return a String that the Controller would use
> for the path.
>
> This allows the ActionForward to act as a Page Controller for the path.
> If the particular page referenced by the path needs any special "chrome"
>
> the Page Controller can set that up. Or, if the path needs to be
> adjusted for Locale or device (PDA, browser, et al), then the Page
> Controller could adjust the path before returning it.
>
> If it were a virtual page, like an dynamic image, merge file, or PDF,
> the Page class could also render the Response, rather than have the
> Action do it.
>
> Right now, the Action is doing double duty. It first acts as a
> Dispatcher that acquires business resources and selects the logical
> view. But, in real life, many pages often need special runtime resources
>
> of their own. So, the Action also serves as a Page Controller for the
> page it selects. Many of us consider that a mixing of concerns, and so
> we start to use some Actions as Dispatchers and others as Page
> Controllers. Tiles also fills this gap and is essentially a hybrid of a
> Compositive View and a Page Controller framework.
>
> I'm thinking that, architecturally, the ActionForward represents some
> resource available to the application, of any type, that can be reached
> by the application's protocol. In an http environment, it's the job of a
>
> Resource object to provide a URI that the Controller can use the reach
> the actual resource. (And, in another environment, perhaps the path
> would not be a URI.)
>
> The Action, in its purest form, represents a Dispatcher. It's the job of
>
> a Dispatcher to select which (logical) Resource will handle the
> response. When we talk about selecting between "success", "failure", or
> "glockenspiel", we're talking about dispatching.
>
> But, in real life, we often can't just dispatch to a page. The page
> needs certain resources to render, often to fill UI controls like select
>
> lists.
>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.
>
> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thing.
I've had similar composition problems and agree that a separation makes
sense. Tiles Controllers can be used to setup page data but that doesn't
always work (especially if you're not using Tiles :-) so I end up chaining
actions. None of the action chaining is due to bus. logic as that's
properly factored into a Service layer; it has to do purely with setting
up page data.
Tiles Controllers are one of the major reasons I use Tiles and I think
it's appropriate to move that concept into the Struts core.
David
>
> The "gotcha" is that, to do its job, the ActionForward type may also
> need to interact with the business layer. It doesn't seem right that the
>
> Page Controller should try to branch to another page, like an Action
> might, if there's an error. But the declarative exception handling might
>
> be able to step in here.
>
> -Ted.
>
> --
> Ted Husted,
> Junit in Action - <http://www.manning.com/massol/>,
> Struts in Action - <http://husted.com/struts/book.html>,
> JSP Site Design -
> <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: ActionForwards, et al (was SuccessAction)
Posted by Mike Jasnowski <mj...@bea.com>.
>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.
Not sure if this comment belongs in the context of here, but I'll throw it
out. We use Tiles and Tiles Controllers heavily, and one thing I dislike
about forwarding to a TileDefinition is that I cannot then easily figure out
which Action I'm forwarding to ( The path names a definition which is the
same for each view in my case).
I'm currently appending information via an extension to the ActionForward,
this extra info is then used in my controller to prepare the appropriate
data for that view. If there was some more transparent way to do this that
would be good.
I currently have one controller per definition, which may encompass several
related views.
> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thing.
-----Original Message-----
From: David Graham [mailto:grahamdavid1980@yahoo.com]
Sent: Monday, August 11, 2003 9:47 AM
To: Struts Developers List
Subject: Re: ActionForwards, et al (was SuccessAction)
--- Ted Husted <hu...@apache.org> wrote:
> David Graham wrote:
> > What I think we're seeing here
> > is that we've outgrown our ActionForward declarations and need some
> new
> > ones. I'm fine with adding a SuccessAction but would really like to
> see
> > us discuss future possibilities in this area.
>
> This may not be what you meant, but I've been thinking that
> ActionForward could use a class extension point, same as ActionMapping.
>
> The idea would be to give ActionForward a type property for a Java
> class. If the property is specified, instead of just taking the path as
> it stands, the Controller would call a "prepare" method on the class,
> passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse.
This may be a good time to add an ActionContext interface instead of
passing all these individual pieces. This would also slightly remove the
dependence on Servlet to allow us more flexibility when we look at the
Portlet API.
>
> The prepare method would return a String that the Controller would use
> for the path.
>
> This allows the ActionForward to act as a Page Controller for the path.
> If the particular page referenced by the path needs any special "chrome"
>
> the Page Controller can set that up. Or, if the path needs to be
> adjusted for Locale or device (PDA, browser, et al), then the Page
> Controller could adjust the path before returning it.
>
> If it were a virtual page, like an dynamic image, merge file, or PDF,
> the Page class could also render the Response, rather than have the
> Action do it.
>
> Right now, the Action is doing double duty. It first acts as a
> Dispatcher that acquires business resources and selects the logical
> view. But, in real life, many pages often need special runtime resources
>
> of their own. So, the Action also serves as a Page Controller for the
> page it selects. Many of us consider that a mixing of concerns, and so
> we start to use some Actions as Dispatchers and others as Page
> Controllers. Tiles also fills this gap and is essentially a hybrid of a
> Compositive View and a Page Controller framework.
>
> I'm thinking that, architecturally, the ActionForward represents some
> resource available to the application, of any type, that can be reached
> by the application's protocol. In an http environment, it's the job of a
>
> Resource object to provide a URI that the Controller can use the reach
> the actual resource. (And, in another environment, perhaps the path
> would not be a URI.)
>
> The Action, in its purest form, represents a Dispatcher. It's the job of
>
> a Dispatcher to select which (logical) Resource will handle the
> response. When we talk about selecting between "success", "failure", or
> "glockenspiel", we're talking about dispatching.
>
> But, in real life, we often can't just dispatch to a page. The page
> needs certain resources to render, often to fill UI controls like select
>
> lists.
>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.
>
> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thing.
I've had similar composition problems and agree that a separation makes
sense. Tiles Controllers can be used to setup page data but that doesn't
always work (especially if you're not using Tiles :-) so I end up chaining
actions. None of the action chaining is due to bus. logic as that's
properly factored into a Service layer; it has to do purely with setting
up page data.
Tiles Controllers are one of the major reasons I use Tiles and I think
it's appropriate to move that concept into the Struts core.
David
>
> The "gotcha" is that, to do its job, the ActionForward type may also
> need to interact with the business layer. It doesn't seem right that the
>
> Page Controller should try to branch to another page, like an Action
> might, if there's an error. But the declarative exception handling might
>
> be able to step in here.
>
> -Ted.
>
> --
> Ted Husted,
> Junit in Action - <http://www.manning.com/massol/>,
> Struts in Action - <http://husted.com/struts/book.html>,
> JSP Site Design -
> <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionForwards, et al (was SuccessAction)
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> David Graham wrote:
> > What I think we're seeing here
> > is that we've outgrown our ActionForward declarations and need some
> new
> > ones. I'm fine with adding a SuccessAction but would really like to
> see
> > us discuss future possibilities in this area.
>
> This may not be what you meant, but I've been thinking that
> ActionForward could use a class extension point, same as ActionMapping.
>
> The idea would be to give ActionForward a type property for a Java
> class. If the property is specified, instead of just taking the path as
> it stands, the Controller would call a "prepare" method on the class,
> passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse.
This may be a good time to add an ActionContext interface instead of
passing all these individual pieces. This would also slightly remove the
dependence on Servlet to allow us more flexibility when we look at the
Portlet API.
>
> The prepare method would return a String that the Controller would use
> for the path.
>
> This allows the ActionForward to act as a Page Controller for the path.
> If the particular page referenced by the path needs any special "chrome"
>
> the Page Controller can set that up. Or, if the path needs to be
> adjusted for Locale or device (PDA, browser, et al), then the Page
> Controller could adjust the path before returning it.
>
> If it were a virtual page, like an dynamic image, merge file, or PDF,
> the Page class could also render the Response, rather than have the
> Action do it.
>
> Right now, the Action is doing double duty. It first acts as a
> Dispatcher that acquires business resources and selects the logical
> view. But, in real life, many pages often need special runtime resources
>
> of their own. So, the Action also serves as a Page Controller for the
> page it selects. Many of us consider that a mixing of concerns, and so
> we start to use some Actions as Dispatchers and others as Page
> Controllers. Tiles also fills this gap and is essentially a hybrid of a
> Compositive View and a Page Controller framework.
>
> I'm thinking that, architecturally, the ActionForward represents some
> resource available to the application, of any type, that can be reached
> by the application's protocol. In an http environment, it's the job of a
>
> Resource object to provide a URI that the Controller can use the reach
> the actual resource. (And, in another environment, perhaps the path
> would not be a URI.)
>
> The Action, in its purest form, represents a Dispatcher. It's the job of
>
> a Dispatcher to select which (logical) Resource will handle the
> response. When we talk about selecting between "success", "failure", or
> "glockenspiel", we're talking about dispatching.
>
> But, in real life, we often can't just dispatch to a page. The page
> needs certain resources to render, often to fill UI controls like select
>
> lists.
>
> Ideally, I believe another class, specified by the ActionForward, should
>
> be responsible for setting up any "chrome" a particular page may need.
> It's the one that knows where the page is (via the path property), and
> so it's the one that should be privy to these details.
>
> What would start to happen here, I think, is that people will put into
> the new class the code that now encourages them to "chain"
> some Actions. By providing a separation of concern between "choosing the
> Resource" and "preparing the context for the Resource", it becomes
> easier for people to Do The Right Thing.
I've had similar composition problems and agree that a separation makes
sense. Tiles Controllers can be used to setup page data but that doesn't
always work (especially if you're not using Tiles :-) so I end up chaining
actions. None of the action chaining is due to bus. logic as that's
properly factored into a Service layer; it has to do purely with setting
up page data.
Tiles Controllers are one of the major reasons I use Tiles and I think
it's appropriate to move that concept into the Struts core.
David
>
> The "gotcha" is that, to do its job, the ActionForward type may also
> need to interact with the business layer. It doesn't seem right that the
>
> Page Controller should try to branch to another page, like an Action
> might, if there's an error. But the declarative exception handling might
>
> be able to step in here.
>
> -Ted.
>
> --
> Ted Husted,
> Junit in Action - <http://www.manning.com/massol/>,
> Struts in Action - <http://husted.com/struts/book.html>,
> JSP Site Design -
> <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
ActionForwards, et al (was SuccessAction)
Posted by Ted Husted <hu...@apache.org>.
David Graham wrote:
> What I think we're seeing here
> is that we've outgrown our ActionForward declarations and need some new
> ones. I'm fine with adding a SuccessAction but would really like to see
> us discuss future possibilities in this area.
This may not be what you meant, but I've been thinking that
ActionForward could use a class extension point, same as ActionMapping.
The idea would be to give ActionForward a type property for a Java
class. If the property is specified, instead of just taking the path as
it stands, the Controller would call a "prepare" method on the class,
passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse.
The prepare method would return a String that the Controller would use
for the path.
This allows the ActionForward to act as a Page Controller for the path.
If the particular page referenced by the path needs any special "chrome"
the Page Controller can set that up. Or, if the path needs to be
adjusted for Locale or device (PDA, browser, et al), then the Page
Controller could adjust the path before returning it.
If it were a virtual page, like an dynamic image, merge file, or PDF,
the Page class could also render the Response, rather than have the
Action do it.
Right now, the Action is doing double duty. It first acts as a
Dispatcher that acquires business resources and selects the logical
view. But, in real life, many pages often need special runtime resources
of their own. So, the Action also serves as a Page Controller for the
page it selects. Many of us consider that a mixing of concerns, and so
we start to use some Actions as Dispatchers and others as Page
Controllers. Tiles also fills this gap and is essentially a hybrid of a
Compositive View and a Page Controller framework.
I'm thinking that, architecturally, the ActionForward represents some
resource available to the application, of any type, that can be reached
by the application's protocol. In an http environment, it's the job of a
Resource object to provide a URI that the Controller can use the reach
the actual resource. (And, in another environment, perhaps the path
would not be a URI.)
The Action, in its purest form, represents a Dispatcher. It's the job of
a Dispatcher to select which (logical) Resource will handle the
response. When we talk about selecting between "success", "failure", or
"glockenspiel", we're talking about dispatching.
But, in real life, we often can't just dispatch to a page. The page
needs certain resources to render, often to fill UI controls like select
lists.
Ideally, I believe another class, specified by the ActionForward, should
be responsible for setting up any "chrome" a particular page may need.
It's the one that knows where the page is (via the path property), and
so it's the one that should be privy to these details.
What would start to happen here, I think, is that people will put into
the new class the code that now encourages them to "chain"
some Actions. By providing a separation of concern between "choosing the
Resource" and "preparing the context for the Resource", it becomes
easier for people to Do The Right Thing.
The "gotcha" is that, to do its job, the ActionForward type may also
need to interact with the business layer. It doesn't seem right that the
Page Controller should try to branch to another page, like an Action
might, if there's an error. But the declarative exception handling might
be able to step in here.
-Ted.
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: SuccessAction (was RE: Addition of two new actions)
Posted by Ted Husted <hu...@apache.org>.
Maverick directly supports the idea that a command may have only one
destrintation, and then streamlines its behavior. So we have some
precedent under the "great minds" theory =:0)
ActionMapping.findForwards only brings back local forwards. So the
"DefaultAction" could just forward to the first and only local forward,
and perhaps throw an exception if there were not exactly one.
Something like
String[] forwards = mapping.findForwards();
if (1!=forwards.length) {
throw new RuntimeException("DefaultAction: Exactly one forward must be
specified");
}
return mapping.findForward(forwards[0]);
-Ted.
Joe Germuska wrote:
> At 16:51 -0700 8/8/03, David Graham wrote:
>
>> I'd like to get your thoughts (and others) on my proposal at the
>> beginning
>> of this message. In short, we wouldn't use the parameter attribute nor
>> would we define "success" as the only correct forward name.
>> SuccessAction
>> would forward to the first <forward> that's defined for it.
>
>
> This sounds like a great compromise, seeing as it would be totally
> compatible with naming the forwards "success", as well as anything else.
> ( I tend to use "page" in the analogous case).
>
> Joe
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: SuccessAction (was RE: Addition of two new actions)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 16:51 -0700 8/8/03, David Graham wrote:
>I'd like to get your thoughts (and others) on my proposal at the beginning
>of this message. In short, we wouldn't use the parameter attribute nor
>would we define "success" as the only correct forward name. SuccessAction
>would forward to the first <forward> that's defined for it.
This sounds like a great compromise, seeing as it would be totally
compatible with naming the forwards "success", as well as anything
else. ( I tend to use "page" in the analogous case).
Joe
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Struts Toolkit (was SuccessAction)
Posted by Steve Raeburn <sr...@apache.org>.
I think the functionality that SuccessAction provides should be part of the
core distribution, particularly as we're encouraging linking only to
actions. This make it a whole lot easier.
I'm sure there's a whole lot of things that can go into a toolkit, but would
it be very different from Scaffold?
Steve
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: August 9, 2003 6:52 AM
> To: Struts Developers List
> Subject: Re: Struts Toolkit (was SuccessAction)
>
>
> First, I don't think there's anything "wrong" with our defining the term
> success to indicate a nominal outcome. Java does the same with terms
> like "true" and "false". I'd also submit that that SUCCESS and FAILURE
> in Globals would be a clear demonstration of an important best practice:
> Use formally-defined Statics for programming elements, such as the names
> of ActionForwards.
>
> But, at the same time, I would caution against shoveling a lot of
> toolkit components into the Actions package. I think the complex
> dispatch-like Actions are fine. But things like a SuccessAction or a
> DefaultAction, et al, might really belong in a "toolkit" package with
> its own release cycle.
>
> I don't think this would be the best time for us to stake out another
> package to distribute. But, when I get to back to work on the Struts
> University thing, I do know that a number of these types of toolkit
> classes will be needed, if best practices are to be demonstrated.
>
> Joe G and I have been talking about setting up a Struts-Toolkit
> distribution on the Struts SourceForge site. This can be home to things
> like "SuccessAction" and some of the more useful Scaffold things, and so
> forth. We can try to release this about the same time as Struts 1.2.0.
>
> The Sourceforge Struts site using a open-door Commons approach. Any
> developer with a *working* Struts-related component to donate is
> eligible for membership as a developer, with write access to everything.
> Though, the binding votes are between the Admin group. Any Struts
> Committer is eligible to be Struts SourceForge Admin (just send us your
> SF ID).
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Toolkit (was SuccessAction)
Posted by Ted Husted <hu...@apache.org>.
First, I don't think there's anything "wrong" with our defining the term
success to indicate a nominal outcome. Java does the same with terms
like "true" and "false". I'd also submit that that SUCCESS and FAILURE
in Globals would be a clear demonstration of an important best practice:
Use formally-defined Statics for programming elements, such as the names
of ActionForwards.
But, at the same time, I would caution against shoveling a lot of
toolkit components into the Actions package. I think the complex
dispatch-like Actions are fine. But things like a SuccessAction or a
DefaultAction, et al, might really belong in a "toolkit" package with
its own release cycle.
I don't think this would be the best time for us to stake out another
package to distribute. But, when I get to back to work on the Struts
University thing, I do know that a number of these types of toolkit
classes will be needed, if best practices are to be demonstrated.
Joe G and I have been talking about setting up a Struts-Toolkit
distribution on the Struts SourceForge site. This can be home to things
like "SuccessAction" and some of the more useful Scaffold things, and so
forth. We can try to release this about the same time as Struts 1.2.0.
The Sourceforge Struts site using a open-door Commons approach. Any
developer with a *working* Struts-related component to donate is
eligible for membership as a developer, with write access to everything.
Though, the binding votes are between the Admin group. Any Struts
Committer is eligible to be Struts SourceForge Admin (just send us your
SF ID).
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: SuccessAction (was RE: Addition of two new actions)
Posted by Steve Raeburn <sr...@apache.org>.
> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> Sent: August 9, 2003 3:56 PM
> To: Struts Developers List
> Subject: RE: SuccessAction (was RE: Addition of two new actions)
>
>
> >
> > If Action actually does something useful, could we go crazy and default
> > the
> > type as well?
> >
> > <action path="/myAction">
> > <forward path="/myPage.jsp"/>
> > </action>
>
> There is a simpler way of doing that:
> <action path="/myAction" forward="/myPage.jsp"/>
>
> The only benefit of SuccessAction was that it allowed you to use the more
> configurable <forward> element to describe the forward so I think
> SuccessAction examples should include <forward> attributes that couldn't
> be done any other way.
>
> Having said all that, I do like that we're trying to get a simpler
> action/forward declaration syntax :-).
>
But forward= doesn't allow you to mix 'n' match context/module relative
forwards :-)
> >
> > Now that's simple. Especially if you allow a global default forward...
> >
> > <action path="/myAction"/>
>
> All we know from this is that there is an action mapped to /myAction but
> we don't know what handles it. Taken by itself, it looks nonsensical and
> would likely cause confusion. This may be a case where it's *too* simple.
>
> David
>
I wasn't being entirely serious with that, just following it to its logical
conclusion. I did say it probably wasn't very useful. But it would work. If
you know that you can define a global default forward then it makes sense.
It does raise the question of whether we want to allow/look for a global
default action. I'm thinking it may be better to insist that each global
forward has a name, just to avoid confusion. Technically, it works but it
might just be too confusing.
Steve.
> >
> > Probably not quite so useful, but nicely minimal!
> >
> > Steve
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: SuccessAction (was RE: Addition of two new actions)
Posted by David Graham <gr...@yahoo.com>.
--- Steve Raeburn <sr...@apache.org> wrote:
> > I thought the whole point was that there would be only one forward
> > and the action would always forward to that forward? In that case,
> > you could count on using the first one.
>
> Just thinking that if an anonymous/default ActionForward were allowed,
> then
> it could also be useful for other actions. In any case, it's better not
> to
> allow a situation where the behaviour is unspecified.
>
> >> You'd probably need to add a method such as getDefaultForward()
> >> to retrieve it.
> >
> > This part seems to be adding complexity to something which was meant
> > to be very simple.
>
> I think it might actually be possible to reduce the visible complexity
> by
> doing that. e.g.
>
> <action path="/myAction"
> type="org.apache.struts.actions.SuccessAction">
> <forward path="/myPage.jsp"/>
> </action>
>
> SuccessAction may not now be best name, but let's stick with it for the
> moment.
>
> To be really radical, we could absorb the behaviour into Action, and
> have it
> check for a default ActionForward and use that, if found. That way
> there's
> no need for a SuccessAction at all. Then you could just do:
>
> <action path="/myAction"
> type="org.apache.struts.action.Action">
> <forward path="/myPage.jsp"/>
> </action>
>
> If Action actually does something useful, could we go crazy and default
> the
> type as well?
>
> <action path="/myAction">
> <forward path="/myPage.jsp"/>
> </action>
There is a simpler way of doing that:
<action path="/myAction" forward="/myPage.jsp"/>
The only benefit of SuccessAction was that it allowed you to use the more
configurable <forward> element to describe the forward so I think
SuccessAction examples should include <forward> attributes that couldn't
be done any other way.
Having said all that, I do like that we're trying to get a simpler
action/forward declaration syntax :-).
>
> Now that's simple. Especially if you allow a global default forward...
>
> <action path="/myAction"/>
All we know from this is that there is an action mapped to /myAction but
we don't know what handles it. Taken by itself, it looks nonsensical and
would likely cause confusion. This may be a case where it's *too* simple.
David
>
> Probably not quite so useful, but nicely minimal!
>
> Steve
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: SuccessAction (was RE: Addition of two new actions)
Posted by Steve Raeburn <sr...@apache.org>.
I've created some patches to try this out and attached them to Bugzilla.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22267
Sorry about the multiple patch files, but WS Studio wouldn't play ball.
I haven't touched Action...yet ;-)
Steve
> -----Original Message-----
> From: Steve Raeburn [mailto:sraeburn@apache.org]
> Sent: August 8, 2003 8:36 PM
> To: Struts Developers List
> Subject: RE: SuccessAction (was RE: Addition of two new actions)
>
>
> > I thought the whole point was that there would be only one forward
> > and the action would always forward to that forward? In that case,
> > you could count on using the first one.
>
> Just thinking that if an anonymous/default ActionForward were
> allowed, then
> it could also be useful for other actions. In any case, it's better not to
> allow a situation where the behaviour is unspecified.
>
> >> You'd probably need to add a method such as getDefaultForward()
> >> to retrieve it.
> >
> > This part seems to be adding complexity to something which was meant
> > to be very simple.
>
> I think it might actually be possible to reduce the visible complexity by
> doing that. e.g.
>
> <action path="/myAction"
> type="org.apache.struts.actions.SuccessAction">
> <forward path="/myPage.jsp"/>
> </action>
>
> SuccessAction may not now be best name, but let's stick with it for the
> moment.
>
> To be really radical, we could absorb the behaviour into Action,
> and have it
> check for a default ActionForward and use that, if found. That way there's
> no need for a SuccessAction at all. Then you could just do:
>
> <action path="/myAction"
> type="org.apache.struts.action.Action">
> <forward path="/myPage.jsp"/>
> </action>
>
> If Action actually does something useful, could we go crazy and
> default the
> type as well?
>
> <action path="/myAction">
> <forward path="/myPage.jsp"/>
> </action>
>
> Now that's simple. Especially if you allow a global default forward...
>
> <action path="/myAction"/>
>
> Probably not quite so useful, but nicely minimal!
>
> Steve
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: SuccessAction (was RE: Addition of two new actions)
Posted by Steve Raeburn <sr...@apache.org>.
> I thought the whole point was that there would be only one forward
> and the action would always forward to that forward? In that case,
> you could count on using the first one.
Just thinking that if an anonymous/default ActionForward were allowed, then
it could also be useful for other actions. In any case, it's better not to
allow a situation where the behaviour is unspecified.
>> You'd probably need to add a method such as getDefaultForward()
>> to retrieve it.
>
> This part seems to be adding complexity to something which was meant
> to be very simple.
I think it might actually be possible to reduce the visible complexity by
doing that. e.g.
<action path="/myAction"
type="org.apache.struts.actions.SuccessAction">
<forward path="/myPage.jsp"/>
</action>
SuccessAction may not now be best name, but let's stick with it for the
moment.
To be really radical, we could absorb the behaviour into Action, and have it
check for a default ActionForward and use that, if found. That way there's
no need for a SuccessAction at all. Then you could just do:
<action path="/myAction"
type="org.apache.struts.action.Action">
<forward path="/myPage.jsp"/>
</action>
If Action actually does something useful, could we go crazy and default the
type as well?
<action path="/myAction">
<forward path="/myPage.jsp"/>
</action>
Now that's simple. Especially if you allow a global default forward...
<action path="/myAction"/>
Probably not quite so useful, but nicely minimal!
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: SuccessAction (was RE: Addition of two new actions)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 18:18 -0700 8/8/03, Steve Raeburn wrote:
>I don't think that you could rely on the ActionForwards being returned in
>the same order each time, so forwarding to the first one found would not be
>guaranteed to work.
I thought the whole point was that there would be only one forward
and the action would always forward to that forward? In that case,
you could count on using the first one.
If order was deemed meaningful, it would be easy enough to use the
SequencedHashMap from Commons Collections.
>Any forward without a name, would be stored under a default key (defined in
>Globals). You could use null here, but I think it would be better to use an
>actual value.
>
>You'd probably need to add a method such as getDefaultForward() to retrieve
>it.
This part seems to be adding complexity to something which was meant
to be very simple.
To be fair, I'm just kibitzing; I dropped off this thread a while
back and don't have very strong feelings either way.
Joe
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: SuccessAction (was RE: Addition of two new actions)
Posted by Steve Raeburn <sr...@apache.org>.
I don't think that you could rely on the ActionForwards being returned in
the same order each time, so forwarding to the first one found would not be
guaranteed to work.
If we allowed anonymous or default ActionForwards would that work?
<action path="/myAction"
type="o.a.s.actions.SuccessAction">
<forward path="/myPage.jsp">
</action>
Any forward without a name, would be stored under a default key (defined in
Globals). You could use null here, but I think it would be better to use an
actual value.
You'd probably need to add a method such as getDefaultForward() to retrieve
it.
I could see this being of use in more than just SuccessAction (or
equivalent). Quite often you're either forwarding to a "success" destination
or returning to the input destination, so anonymous forwards would save a
bit of work.
I'll go have a play with this and see what I come up with.
Steve
> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> Sent: August 8, 2003 4:51 PM
> To: Struts Developers List
> Subject: Re: SuccessAction (was RE: Addition of two new actions)
>
>
> --- Steve Raeburn <sr...@apache.org> wrote:
> > 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.
>
> That's a good point which raises another question. If the goal of
> SuccessAction is to forward to the one defined <forward> instance, why
> must we name it "success" or "oops"? Why can't SuccessAction call
> mapping.findForwards() and return the first forward it finds? Then we
> don't need to use the parameter attribute nor do we need to declare that
> "success" is the one right name for the forward.
>
> However, that makes SuccessAction a bit silly. If it's just going to
> forward to the first <forward> it finds, why not change the way we define
> forwards to be more natural and flexible? What I think we're seeing here
> is that we've outgrown our ActionForward declarations and need some new
> ones. I'm fine with adding a SuccessAction but would really like to see
> us discuss future possibilities in this area.
>
> >
> > 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).
>
> In its proposed default state SuccessAction would still be a complete
> no-brainer.
>
> >
> > 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.
>
> I've never said that "success" is a poor term or isn't used in most cases.
> I just don't think Struts should dictate the names of forwards to users.
> That is there choice and should be configurable.
>
> We all know that Action chaining isn't generally a smart move but
> sometimes it works out ok. Consider a RegisterAction that forwards to a
> LoginAction to login a user immediately after they register.
> RegisterAction might want to name its success forward "login".
> Admittedly, this isn't directly applicable to our SuccessAction situation
> but it does show that "success" isn't *always* the correct term. Also,
> not every Struts developer speaks english and may choose forward names in
> their native language.
>
> >
> > 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 ;-)
>
> I'd like to get your thoughts (and others) on my proposal at the beginning
> of this message. In short, we wouldn't use the parameter attribute nor
> would we define "success" as the only correct forward name. SuccessAction
> would forward to the first <forward> that's defined for it.
>
> I believe SuccessAction fills a current gap but is probably a temporary
> solution until we have a more unified/flexible forward declaration syntax.
> How "temporary" it is depends on how motivated we are to change it :-).
>
> David
>
> >
> > Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: SuccessAction (was RE: Addition of two new actions)
Posted by David Graham <gr...@yahoo.com>.
--- Steve Raeburn <sr...@apache.org> wrote:
> 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.
That's a good point which raises another question. If the goal of
SuccessAction is to forward to the one defined <forward> instance, why
must we name it "success" or "oops"? Why can't SuccessAction call
mapping.findForwards() and return the first forward it finds? Then we
don't need to use the parameter attribute nor do we need to declare that
"success" is the one right name for the forward.
However, that makes SuccessAction a bit silly. If it's just going to
forward to the first <forward> it finds, why not change the way we define
forwards to be more natural and flexible? What I think we're seeing here
is that we've outgrown our ActionForward declarations and need some new
ones. I'm fine with adding a SuccessAction but would really like to see
us discuss future possibilities in this area.
>
> 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).
In its proposed default state SuccessAction would still be a complete
no-brainer.
>
> 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.
I've never said that "success" is a poor term or isn't used in most cases.
I just don't think Struts should dictate the names of forwards to users.
That is there choice and should be configurable.
We all know that Action chaining isn't generally a smart move but
sometimes it works out ok. Consider a RegisterAction that forwards to a
LoginAction to login a user immediately after they register.
RegisterAction might want to name its success forward "login".
Admittedly, this isn't directly applicable to our SuccessAction situation
but it does show that "success" isn't *always* the correct term. Also,
not every Struts developer speaks english and may choose forward names in
their native language.
>
> 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 ;-)
I'd like to get your thoughts (and others) on my proposal at the beginning
of this message. In short, we wouldn't use the parameter attribute nor
would we define "success" as the only correct forward name. SuccessAction
would forward to the first <forward> that's defined for it.
I believe SuccessAction fills a current gap but is probably a temporary
solution until we have a more unified/flexible forward declaration syntax.
How "temporary" it is depends on how motivated we are to change it :-).
David
>
> Steve
>
>
> > -----Original Message-----
> > From: David Graham [mailto:grahamdavid1980@yahoo.com]
> > Sent: August 5, 2003 6:52 AM
> > To: Struts Developers List
> > Subject: RE: Addition of two new actions
> >
> >
> > --- Steve Raeburn <sr...@apache.org> 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:grahamdavid1980@yahoo.com]
> > > > Sent: August 4, 2003 3:06 PM
> > > > To: Struts Developers List
> > > > Subject: RE: Addition of two new actions
> > > >
> > > >
> > > > --- Steve Raeburn <sr...@apache.org> 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:grahamdavid1980@yahoo.com]
> > > > > > Sent: August 4, 2003 1:32 PM
> > > > > > To: Struts Developers List
> > > > > > Subject: RE: Addition of two new actions
> > > > > >
> > > > > >
> > > > > > --- Steve Raeburn <sr...@apache.org> 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
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org