Re: RE: SuccessAction (was RE: Addition of two new actions)
hi ,all: how can I send my questions to all of you ? Could you tell me ? Thanks~~ mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
Is this a vote? If so, shouldn't we have [VOTE] on the subject line? -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 AIM:jmitchtx > -Original Message- > From: Steve Raeburn [mailto:[EMAIL PROTECTED] > Sent: Friday, August 08, 2003 5:38 PM > To: Struts Developers List > Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: > Addition of two new actions) > > > I *think* we agreed to add this action. Pick a name. > > [ ] ParameterDispatchAction > [ ] MappingDispatchAction > [ ] ConfigDispatchAction > > Steve > > > -Original Message- > > From: Steve Raeburn [mailto:[EMAIL PROTECTED] > > Sent: August 4, 2003 1:25 PM > > To: Struts Developers List > > Subject: RE: Addition of two new actions > > > > > > In an ideal world, DispatchAction should probably become > > ParameterDispatchAction and this could be plain old DispatchAction. > > > > Is Anthony's original suggestion of ConfigDispatchAction any better? > > > > I can't think of a name that I *really* like so I'm +0 on Mapping > > or Config. > > > > Steve > > > > > -Original Message- > > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper > > > Sent: August 4, 2003 10:15 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Addition of two new actions > > > > > > I'm +1 on this, other than on naming. I think > ParameterDispatchAction is > > > definitely the wrong name for the last of these. People > are *far* more > > > likely to think of the "Parameter" in the name as meaning > a request > > > parameter than they are to think of the "parameter" action mapping > > > attribute. Perhaps MappingDispatchAction instead? > > > > > > I am -0 on combining all of this into one action. > > > > > > -- > > > Martin Cooper > > > > > > > > > > > > > > > - > > 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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SuccessAction (was RE: Addition of two new actions)
--- Steve Raeburn <[EMAIL PROTECTED]> 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. > > type="org.apache.struts.actions.SuccessAction"> > > > > 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: > > type="org.apache.struts.action.Action"> > > > > If Action actually does something useful, could we go crazy and default > the > type as well? > > > > There is a simpler way of doing that: The only benefit of SuccessAction was that it allowed you to use the more configurable element to describe the forward so I think SuccessAction examples should include 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... > > 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: [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]
Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º >Is this a vote? If so, shouldn't we have [VOTE] on the subject line?of you ? Could >you tell me ? Thanks~~ > > >-- >James Mitchell >Software Engineer / Struts Evangelist >http://www.struts-atlanta.org >678.910.8017 >AIM:jmitchtx > > > > >> -Original Message- >> From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> Sent: Friday, August 08, 2003 5:38 PM >> To: Struts Developers List >> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: >> Addition of two new actions) >> >> >> I *think* we agreed to add this action. Pick a name. >> >> [ ] ParameterDispatchAction >> [ ] MappingDispatchAction >> [ ] ConfigDispatchAction >> >> Steve >> >> > -Original Message----- >> > From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> > Sent: August 4, 2003 1:25 PM >> > To: Struts Developers List >> > Subject: RE: Addition of two new actions >> > >> > >> > In an ideal world, DispatchAction should probably become >> > ParameterDispatchAction and this could be plain old DispatchAction. >> > >> > Is Anthony's original suggestion of ConfigDispatchAction any better? >> > >> > I can't think of a name that I *really* like so I'm +0 on Mapping >> > or Config. >> > >> > Steve >> > >> > > -Original Message- >> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper >> > > Sent: August 4, 2003 10:15 AM >> > > To: [EMAIL PROTECTED] >> > > Subject: Re: Addition of two new actions >> > > >> > > I'm +1 on this, other than on naming. I think >> ParameterDispatchAction is >> > > definitely the wrong name for the last of these. People >> are *far* more >> > > likely to think of the "Parameter" in the name as meaning >> a request >> > > parameter than they are to think of the "parameter" action mapping >> > > attribute. Perhaps MappingDispatchAction instead? >> > > >> > > I am -0 on combining all of this into one action. >> > > >> > > -- >> > > Martin Cooper >> > > >> > > >> > >> > >> > >> > >> - >> > 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] >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
+1 Steve Raeburn wrote: This is not a general purpose action. It is intended to do just one thing and that's forward the request to one place. 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. 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. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: SuccessAction (was RE: Addition of two new actions)
hi ,all: how can I send my questions to all of you ? Could you tell me ? Thanks~~ mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SuccessAction (was RE: Addition of two new actions)
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 [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SuccessAction (was RE: Addition of two new actions)
> -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > 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? > > > > > > > > > > There is a simpler way of doing that: > > > The only benefit of SuccessAction was that it allowed you to use the more > configurable element to describe the forward so I think > SuccessAction examples should include 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... > > > > > > 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: [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]
Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º >Is this a vote? If so, shouldn't we have [VOTE] on the subject line?of you ? Could >you tell me ? Thanks~~ > > >-- >James Mitchell >Software Engineer / Struts Evangelist >http://www.struts-atlanta.org >678.910.8017 >AIM:jmitchtx > > > > >> -Original Message- >> From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> Sent: Friday, August 08, 2003 5:38 PM >> To: Struts Developers List >> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: >> Addition of two new actions) >> >> >> I *think* we agreed to add this action. Pick a name. >> >> [ ] ParameterDispatchAction >> [ ] MappingDispatchAction >> [ ] ConfigDispatchAction >> >> Steve >> >> > -Original Message----- >> > From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> > Sent: August 4, 2003 1:25 PM >> > To: Struts Developers List >> > Subject: RE: Addition of two new actions >> > >> > >> > In an ideal world, DispatchAction should probably become >> > ParameterDispatchAction and this could be plain old DispatchAction. >> > >> > Is Anthony's original suggestion of ConfigDispatchAction any better? >> > >> > I can't think of a name that I *really* like so I'm +0 on Mapping >> > or Config. >> > >> > Steve >> > >> > > -Original Message- >> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper >> > > Sent: August 4, 2003 10:15 AM >> > > To: [EMAIL PROTECTED] >> > > Subject: Re: Addition of two new actions >> > > >> > > I'm +1 on this, other than on naming. I think >> ParameterDispatchAction is >> > > definitely the wrong name for the last of these. People >> are *far* more >> > > likely to think of the "Parameter" in the name as meaning >> a request >> > > parameter than they are to think of the "parameter" action mapping >> > > attribute. Perhaps MappingDispatchAction instead? >> > > >> > > I am -0 on combining all of this into one action. >> > > >> > > -- >> > > Martin Cooper >> > > >> > > >> > >> > >> > >> > >> - >> > 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] >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
Yup. What Ted said. :-) I'm still feeling my way here, but does this kind of change *need* a formal vote? Steve > -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: August 9, 2003 6:03 AM > To: Struts Developers List > Subject: Re: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of > two new actions) > > > I'd say it was more like a poll to get an early consensus on the best > name for the class. Any product change would still be subject to a veto > before the next release. > > James Mitchell wrote: > > Is this a vote? If so, shouldn't we have [VOTE] on the subject line? > >> > >>I *think* we agreed to add this action. Pick a name. > >> > >>[ ] ParameterDispatchAction > >>[ ] MappingDispatchAction > >>[ ] ConfigDispatchAction > >> > > > > - > 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]
Re: SuccessAction (was RE: Addition of two new actions)
--- Steve Raeburn <[EMAIL PROTECTED]> wrote: > OK, I'm back. Now where were we... > > What you're suggesting is this? > > type="o.a.s.actions.SuccessAction"> > > > > type="o.a.s.actions.SuccessAction" > parameter="oops"> > > > > 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 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 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 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:[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. > > > > >
SuccessAction (was RE: Addition of two new actions)
OK, I'm back. Now where were we... What you're suggesting is this? 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 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 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 > > 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 or ForwardAction. How would > > > > adding > > > > it be bad for Struts? > > > > > > One thing that r
Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º >Is this a vote? If so, shouldn't we have [VOTE] on the subject line?of you ? Could >you tell me ? Thanks~~ > > >-- >James Mitchell >Software Engineer / Struts Evangelist >http://www.struts-atlanta.org >678.910.8017 >AIM:jmitchtx > > > > >> -Original Message- >> From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> Sent: Friday, August 08, 2003 5:38 PM >> To: Struts Developers List >> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: >> Addition of two new actions) >> >> >> I *think* we agreed to add this action. Pick a name. >> >> [ ] ParameterDispatchAction >> [ ] MappingDispatchAction >> [ ] ConfigDispatchAction >> >> Steve >> >> > -Original Message----- >> > From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> > Sent: August 4, 2003 1:25 PM >> > To: Struts Developers List >> > Subject: RE: Addition of two new actions >> > >> > >> > In an ideal world, DispatchAction should probably become >> > ParameterDispatchAction and this could be plain old DispatchAction. >> > >> > Is Anthony's original suggestion of ConfigDispatchAction any better? >> > >> > I can't think of a name that I *really* like so I'm +0 on Mapping >> > or Config. >> > >> > Steve >> > >> > > -Original Message- >> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper >> > > Sent: August 4, 2003 10:15 AM >> > > To: [EMAIL PROTECTED] >> > > Subject: Re: Addition of two new actions >> > > >> > > I'm +1 on this, other than on naming. I think >> ParameterDispatchAction is >> > > definitely the wrong name for the last of these. People >> are *far* more >> > > likely to think of the "Parameter" in the name as meaning >> a request >> > > parameter than they are to think of the "parameter" action mapping >> > > attribute. Perhaps MappingDispatchAction instead? >> > > >> > > I am -0 on combining all of this into one action. >> > > >> > > -- >> > > Martin Cooper >> > > >> > > >> > >> > >> > >> > >> - >> > 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] >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: SuccessAction (was RE: Addition of two new actions)
ÔÚ 2003-08-08 21:15:00 ÄúдµÀ£º >I've created some patches to try this out and attached them to Bugzilla.of you ? >Could you tell me ? Thanks~~ >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:[EMAIL PROTECTED] >> 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. >> >> > type="org.apache.struts.actions.SuccessAction"> >> >> >> >> 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: >> >> > type="org.apache.struts.action.Action"> >> >> >> >> If Action actually does something useful, could we go crazy and >> default the >> type as well? >> >> >> >> >> >> Now that's simple. Especially if you allow a global default forward... >> >> >> >> Probably not quite so useful, but nicely minimal! >> >> Steve >> >> >> >> - >> 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] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
I *think* we agreed to add this action. Pick a name. [ ] ParameterDispatchAction [ ] MappingDispatchAction [ ] ConfigDispatchAction Steve > -Original Message- > From: Steve Raeburn [mailto:[EMAIL PROTECTED] > Sent: August 4, 2003 1:25 PM > To: Struts Developers List > Subject: RE: Addition of two new actions > > > In an ideal world, DispatchAction should probably become > ParameterDispatchAction and this could be plain old DispatchAction. > > Is Anthony's original suggestion of ConfigDispatchAction any better? > > I can't think of a name that I *really* like so I'm +0 on Mapping > or Config. > > Steve > > > -Original Message- > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper > > Sent: August 4, 2003 10:15 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Addition of two new actions > > > > I'm +1 on this, other than on naming. I think ParameterDispatchAction is > > definitely the wrong name for the last of these. People are *far* more > > likely to think of the "Parameter" in the name as meaning a request > > parameter than they are to think of the "parameter" action mapping > > attribute. Perhaps MappingDispatchAction instead? > > > > I am -0 on combining all of this into one action. > > > > -- > > Martin Cooper > > > > > > > > - > 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]
Re: RE: SuccessAction (was RE: Addition of two new actions)
ÔÚ 2003-08-08 21:15:00 ÄúдµÀ£º >I've created some patches to try this out and attached them to Bugzilla.of you ? >Could you tell me ? Thanks~~ >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:[EMAIL PROTECTED] >> 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. >> >> > type="org.apache.struts.actions.SuccessAction"> >> >> >> >> 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: >> >> > type="org.apache.struts.action.Action"> >> >> >> >> If Action actually does something useful, could we go crazy and >> default the >> type as well? >> >> >> >> >> >> Now that's simple. Especially if you allow a global default forward... >> >> >> >> Probably not quite so useful, but nicely minimal! >> >> Steve >> >> >> >> - >> 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] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. 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: If Action actually does something useful, could we go crazy and default the type as well? Now that's simple. Especially if you allow a global default forward... Probably not quite so useful, but nicely minimal! Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º >Is this a vote? If so, shouldn't we have [VOTE] on the subject line?of you ? Could >you tell me ? Thanks~~ > > >-- >James Mitchell >Software Engineer / Struts Evangelist >http://www.struts-atlanta.org >678.910.8017 >AIM:jmitchtx > > > > >> -Original Message- >> From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> Sent: Friday, August 08, 2003 5:38 PM >> To: Struts Developers List >> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: >> Addition of two new actions) >> >> >> I *think* we agreed to add this action. Pick a name. >> >> [ ] ParameterDispatchAction >> [ ] MappingDispatchAction >> [ ] ConfigDispatchAction >> >> Steve >> >> > -Original Message----- >> > From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> > Sent: August 4, 2003 1:25 PM >> > To: Struts Developers List >> > Subject: RE: Addition of two new actions >> > >> > >> > In an ideal world, DispatchAction should probably become >> > ParameterDispatchAction and this could be plain old DispatchAction. >> > >> > Is Anthony's original suggestion of ConfigDispatchAction any better? >> > >> > I can't think of a name that I *really* like so I'm +0 on Mapping >> > or Config. >> > >> > Steve >> > >> > > -Original Message- >> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper >> > > Sent: August 4, 2003 10:15 AM >> > > To: [EMAIL PROTECTED] >> > > Subject: Re: Addition of two new actions >> > > >> > > I'm +1 on this, other than on naming. I think >> ParameterDispatchAction is >> > > definitely the wrong name for the last of these. People >> are *far* more >> > > likely to think of the "Parameter" in the name as meaning >> a request >> > > parameter than they are to think of the "parameter" action mapping >> > > attribute. Perhaps MappingDispatchAction instead? >> > > >> > > I am -0 on combining all of this into one action. >> > > >> > > -- >> > > Martin Cooper >> > > >> > > >> > >> > >> > >> > >> - >> > 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] >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: SuccessAction (was RE: Addition of two new actions)
ÔÚ 2003-08-08 21:15:00 ÄúдµÀ£º >I've created some patches to try this out and attached them to Bugzilla.of you ? >Could you tell me ? Thanks~~ >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:[EMAIL PROTECTED] >> 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. >> >> > type="org.apache.struts.actions.SuccessAction"> >> >> >> >> 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: >> >> > type="org.apache.struts.action.Action"> >> >> >> >> If Action actually does something useful, could we go crazy and >> default the >> type as well? >> >> >> >> >> >> Now that's simple. Especially if you allow a global default forward... >> >> >> >> Probably not quite so useful, but nicely minimal! >> >> Steve >> >> >> >> - >> 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] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: SuccessAction (was RE: Addition of two new actions)
ÔÚ 2003-08-08 21:15:00 ÄúдµÀ£º >I've created some patches to try this out and attached them to Bugzilla.of you ? >Could you tell me ? Thanks~~ >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:[EMAIL PROTECTED] >> 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. >> >> > type="org.apache.struts.actions.SuccessAction"> >> >> >> >> 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: >> >> > type="org.apache.struts.action.Action"> >> >> >> >> If Action actually does something useful, could we go crazy and >> default the >> type as well? >> >> >> >> >> >> Now that's simple. Especially if you allow a global default forward... >> >> >> >> Probably not quite so useful, but nicely minimal! >> >> Steve >> >> >> >> - >> 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] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
Internationalisation doesn't/can't apply to the naming of classes. We'd have to rewrite the whole framework for each language. Ted raised the issue in regard to naming of the action forward, but also addressed that point himself. Steve > -Original Message- > From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED] > Sent: August 9, 2003 3:13 AM > To: Struts Developers List > Subject: Re: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of > two new actions) > > > Steve Raeburn wrote: > > I *think* we agreed to add this action. Pick a name. > > > > [ ] ParameterDispatchAction > > [ ] MappingDispatchAction > > [ ] ConfigDispatchAction > > > > Steve > > > > What happens if English is not your mother language. > Are you suggesting we have? > > ErfolgreichAction -- German > > ExitosAction -- Spanish > > If we have Global.SUCCESS_FORWARD and Global.FAILURE_FORWARD > to represent common ActionForward names it might help. > Ted Husted suggests such naming in his book, but if program > your variables with name that are non-english then you > may not agree this. > > -- > Peter Pilgrim > __ _ _ _ >/ //__ // ___// ___/ + Serverside Java > / /___/ // /__ / /__ + Struts > / // ___// ___// ___/ + Expresso Committer > __/ // /__ / /__ / /__ + Independent Contractor > /___/////// + Intrinsic Motivation > On Line Resume > || > \\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' > > > - > 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]
Re: RE: SuccessAction (was RE: Addition of two new actions)
ÔÚ 2003-08-08 21:15:00 ÄúдµÀ£º >I've created some patches to try this out and attached them to Bugzilla.of you ? >Could you tell me ? Thanks~~ >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:[EMAIL PROTECTED] >> 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. >> >> > type="org.apache.struts.actions.SuccessAction"> >> >> >> >> 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: >> >> > type="org.apache.struts.action.Action"> >> >> >> >> If Action actually does something useful, could we go crazy and >> default the >> type as well? >> >> >> >> >> >> Now that's simple. Especially if you allow a global default forward... >> >> >> >> Probably not quite so useful, but nicely minimal! >> >> Steve >> >> >> >> - >> 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] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SuccessAction (was RE: Addition of two new actions)
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 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 - ,
JSP Site Design - .
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Addition of two new actions
Please correct me if I'm wrong, but that still doesn't enable you to specify one to be context relative and another module relative within the same module as you can by using 'contextRelative' attribute on a . Steve > -Original Message- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper > Sent: August 4, 2003 3:23 PM > To: [EMAIL PROTECTED] > Subject: Re: Addition of two new actions > > > > "Steve Raeburn" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > You're right is module relative (despite > what it says > in > > the Javadoc). However, I don't see how it can used with a > context relative > > path. > > You might want to take a look at the 'forwardPattern' attribute, and the > RequestUtils.forwardURL() method (especially the JavaDoc for the latter). > > -- > Martin Cooper > > > > > > There is no contextRelative attribute on the action config so you don't > get > > to choose (or change) how your forward works. > > > > Of the three ways of defining forwards that you identified only one, > > , 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. > > > > Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º >Is this a vote? If so, shouldn't we have [VOTE] on the subject line?of you ? Could >you tell me ? Thanks~~ > > >-- >James Mitchell >Software Engineer / Struts Evangelist >http://www.struts-atlanta.org >678.910.8017 >AIM:jmitchtx > > > > >> -Original Message- >> From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> Sent: Friday, August 08, 2003 5:38 PM >> To: Struts Developers List >> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: >> Addition of two new actions) >> >> >> I *think* we agreed to add this action. Pick a name. >> >> [ ] ParameterDispatchAction >> [ ] MappingDispatchAction >> [ ] ConfigDispatchAction >> >> Steve >> >> > -Original Message----- >> > From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> > Sent: August 4, 2003 1:25 PM >> > To: Struts Developers List >> > Subject: RE: Addition of two new actions >> > >> > >> > In an ideal world, DispatchAction should probably become >> > ParameterDispatchAction and this could be plain old DispatchAction. >> > >> > Is Anthony's original suggestion of ConfigDispatchAction any better? >> > >> > I can't think of a name that I *really* like so I'm +0 on Mapping >> > or Config. >> > >> > Steve >> > >> > > -Original Message- >> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper >> > > Sent: August 4, 2003 10:15 AM >> > > To: [EMAIL PROTECTED] >> > > Subject: Re: Addition of two new actions >> > > >> > > I'm +1 on this, other than on naming. I think >> ParameterDispatchAction is >> > > definitely the wrong name for the last of these. People >> are *far* more >> > > likely to think of the "Parameter" in the name as meaning >> a request >> > > parameter than they are to think of the "parameter" action mapping >> > > attribute. Perhaps MappingDispatchAction instead? >> > > >> > > I am -0 on combining all of this into one action. >> > > >> > > -- >> > > Martin Cooper >> > > >> > > >> > >> > >> > >> > >> - >> > 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] >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SuccessAction (was RE: Addition of two new actions)
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:[EMAIL PROTECTED] > 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. > > type="org.apache.struts.actions.SuccessAction"> > > > > 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: > > type="org.apache.struts.action.Action"> > > > > If Action actually does something useful, could we go crazy and > default the > type as well? > > > > > > Now that's simple. Especially if you allow a global default forward... > > > > Probably not quite so useful, but nicely minimal! > > Steve > > > > - > 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]
Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º >Is this a vote? If so, shouldn't we have [VOTE] on the subject line?of you ? Could >you tell me ? Thanks~~ > > >-- >James Mitchell >Software Engineer / Struts Evangelist >http://www.struts-atlanta.org >678.910.8017 >AIM:jmitchtx > > > > >> -Original Message- >> From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> Sent: Friday, August 08, 2003 5:38 PM >> To: Struts Developers List >> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: >> Addition of two new actions) >> >> >> I *think* we agreed to add this action. Pick a name. >> >> [ ] ParameterDispatchAction >> [ ] MappingDispatchAction >> [ ] ConfigDispatchAction >> >> Steve >> >> > -Original Message----- >> > From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> > Sent: August 4, 2003 1:25 PM >> > To: Struts Developers List >> > Subject: RE: Addition of two new actions >> > >> > >> > In an ideal world, DispatchAction should probably become >> > ParameterDispatchAction and this could be plain old DispatchAction. >> > >> > Is Anthony's original suggestion of ConfigDispatchAction any better? >> > >> > I can't think of a name that I *really* like so I'm +0 on Mapping >> > or Config. >> > >> > Steve >> > >> > > -Original Message- >> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper >> > > Sent: August 4, 2003 10:15 AM >> > > To: [EMAIL PROTECTED] >> > > Subject: Re: Addition of two new actions >> > > >> > > I'm +1 on this, other than on naming. I think >> ParameterDispatchAction is >> > > definitely the wrong name for the last of these. People >> are *far* more >> > > likely to think of the "Parameter" in the name as meaning >> a request >> > > parameter than they are to think of the "parameter" action mapping >> > > attribute. Perhaps MappingDispatchAction instead? >> > > >> > > I am -0 on combining all of this into one action. >> > > >> > > -- >> > > Martin Cooper >> > > >> > > >> > >> > >> > >> > >> - >> > 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] >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º >Is this a vote? If so, shouldn't we have [VOTE] on the subject line?of you ? Could >you tell me ? Thanks~~ > > >-- >James Mitchell >Software Engineer / Struts Evangelist >http://www.struts-atlanta.org >678.910.8017 >AIM:jmitchtx > > > > >> -Original Message- >> From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> Sent: Friday, August 08, 2003 5:38 PM >> To: Struts Developers List >> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: >> Addition of two new actions) >> >> >> I *think* we agreed to add this action. Pick a name. >> >> [ ] ParameterDispatchAction >> [ ] MappingDispatchAction >> [ ] ConfigDispatchAction >> >> Steve >> >> > -Original Message----- >> > From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> > Sent: August 4, 2003 1:25 PM >> > To: Struts Developers List >> > Subject: RE: Addition of two new actions >> > >> > >> > In an ideal world, DispatchAction should probably become >> > ParameterDispatchAction and this could be plain old DispatchAction. >> > >> > Is Anthony's original suggestion of ConfigDispatchAction any better? >> > >> > I can't think of a name that I *really* like so I'm +0 on Mapping >> > or Config. >> > >> > Steve >> > >> > > -Original Message- >> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper >> > > Sent: August 4, 2003 10:15 AM >> > > To: [EMAIL PROTECTED] >> > > Subject: Re: Addition of two new actions >> > > >> > > I'm +1 on this, other than on naming. I think >> ParameterDispatchAction is >> > > definitely the wrong name for the last of these. People >> are *far* more >> > > likely to think of the "Parameter" in the name as meaning >> a request >> > > parameter than they are to think of the "parameter" action mapping >> > > attribute. Perhaps MappingDispatchAction instead? >> > > >> > > I am -0 on combining all of this into one action. >> > > >> > > -- >> > > Martin Cooper >> > > >> > > >> > >> > >> > >> > >> - >> > 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] >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
ÔÚ 2003-08-09 03:01:00 ÄúдµÀ£º >Is this a vote? If so, shouldn't we have [VOTE] on the subject line?of you ? Could >you tell me ? Thanks~~ > > >-- >James Mitchell >Software Engineer / Struts Evangelist >http://www.struts-atlanta.org >678.910.8017 >AIM:jmitchtx > > > > >> -Original Message- >> From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> Sent: Friday, August 08, 2003 5:38 PM >> To: Struts Developers List >> Subject: Parameter/Mapping/ConfigDispatchAction (Was RE: >> Addition of two new actions) >> >> >> I *think* we agreed to add this action. Pick a name. >> >> [ ] ParameterDispatchAction >> [ ] MappingDispatchAction >> [ ] ConfigDispatchAction >> >> Steve >> >> > -Original Message----- >> > From: Steve Raeburn [mailto:[EMAIL PROTECTED] >> > Sent: August 4, 2003 1:25 PM >> > To: Struts Developers List >> > Subject: RE: Addition of two new actions >> > >> > >> > In an ideal world, DispatchAction should probably become >> > ParameterDispatchAction and this could be plain old DispatchAction. >> > >> > Is Anthony's original suggestion of ConfigDispatchAction any better? >> > >> > I can't think of a name that I *really* like so I'm +0 on Mapping >> > or Config. >> > >> > Steve >> > >> > > -Original Message- >> > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper >> > > Sent: August 4, 2003 10:15 AM >> > > To: [EMAIL PROTECTED] >> > > Subject: Re: Addition of two new actions >> > > >> > > I'm +1 on this, other than on naming. I think >> ParameterDispatchAction is >> > > definitely the wrong name for the last of these. People >> are *far* more >> > > likely to think of the "Parameter" in the name as meaning >> a request >> > > parameter than they are to think of the "parameter" action mapping >> > > attribute. Perhaps MappingDispatchAction instead? >> > > >> > > I am -0 on combining all of this into one action. >> > > >> > > -- >> > > Martin Cooper >> > > >> > > >> > >> > >> > >> > >> - >> > 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] >> > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `--> http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SuccessAction (was RE: Addition of two new actions)
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 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 [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SuccessAction (was RE: Addition of two new actions)
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? 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:[EMAIL PROTECTED] > Sent: August 8, 2003 4:51 PM > To: Struts Developers List > Subject: Re: SuccessAction (was RE: Addition of two new actions) > > > --- Steve Raeburn <[EMAIL PROTECTED]> wrote: > > OK, I'm back. Now where were we... > > > > What you're suggesting is this? > > > >> type="o.a.s.actions.SuccessAction"> > > > > > > > >> type="o.a.s.actions.SuccessAction" > > parameter="oops"> > > > > > > > > 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 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 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
Re: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
--- Steve Raeburn <[EMAIL PROTECTED]> wrote: > I *think* we agreed to add this action. Pick a name. > > [ ] ParameterDispatchAction > [X] MappingDispatchAction > [ ] ConfigDispatchAction I agree with Martin that Parameter implies request parameter and I think Config is overly general so I chose Mapping. David > > Steve > > > -Original Message- > > From: Steve Raeburn [mailto:[EMAIL PROTECTED] > > Sent: August 4, 2003 1:25 PM > > To: Struts Developers List > > Subject: RE: Addition of two new actions > > > > > > In an ideal world, DispatchAction should probably become > > ParameterDispatchAction and this could be plain old DispatchAction. > > > > Is Anthony's original suggestion of ConfigDispatchAction any better? > > > > I can't think of a name that I *really* like so I'm +0 on Mapping > > or Config. > > > > Steve > > > > > -Original Message- > > > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper > > > Sent: August 4, 2003 10:15 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Addition of two new actions > > > > > > I'm +1 on this, other than on naming. I think > ParameterDispatchAction is > > > definitely the wrong name for the last of these. People are *far* > more > > > likely to think of the "Parameter" in the name as meaning a request > > > parameter than they are to think of the "parameter" action mapping > > > attribute. Perhaps MappingDispatchAction instead? > > > > > > I am -0 on combining all of this into one action. > > > > > > -- > > > Martin Cooper > > > > > > > > > > > > > > - > > 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]
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 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 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 > 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 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 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 > > > > b
RE: Addition of two new actions
This is not a general purpose action. It is intended to do just one thing and that's forward the request to one place. 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. 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. 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 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 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 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, > > > > , 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]
Re: Addition of two new actions
"Steve Raeburn" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > You're right is module relative (despite what it says in > the Javadoc). However, I don't see how it can used with a context relative > path. You might want to take a look at the 'forwardPattern' attribute, and the RequestUtils.forwardURL() method (especially the JavaDoc for the latter). -- Martin Cooper > > There is no contextRelative attribute on the action config so you don't get > to choose (or change) how your forward works. > > Of the three ways of defining forwards that you identified only one, > , 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. > > Steve > > > -Original Message- > > From: David Graham [mailto:[EMAIL PROTECTED] > > Sent: August 4, 2003 7:03 AM > > To: Struts Developers List > > Subject: RE: Addition of two new actions > > > > > > Thanks for the link. I'll respond to that message here: > > > > > I'm also throwing an exception if the "success" ActionForward is not > > found to make the configuration problem very clear. > > > > ForwardAction also throws an exception if the path is not found. > > > > > ForwardAction and using 'forward= ' on the ActionMapping both require a > > > context relative path. > > > > That's not accurate, and both default to > > module relative paths. changes the > > default. ForwardAction itself always returns a context relative > > ActionForward but I'd rather see that changed than add a new class. > > > > > In addition, tools vendors may be better able to validate a regular > > > ActionFoward configuration than the ForwardAction where the path is > > > specified via the all-purpose 'parameter'. In order to validate the path > > as > > > a parameter, you require knowledge of the Action class whereas the path > > of > > > an ActionForward definition can be more easily validated. (I'm basing > > this > > > on my experience with WebSphere Studio). > > > > There are many ways of defining forwards: > > > > > > > > > > > parameter="/jsp/input.jsp"/> > > > > Some of these allow better path validation than others but I don't see why > > we need yet another Action class when we could just improve upon the > > existing options. > > > > David > > > > > Steve > > > > --- Steve Raeburn <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > > > From: David Graham [mailto:[EMAIL PROTECTED] > > > > Sent: August 3, 2003 3:02 PM > > > > To: Struts Developers List > > > > Subject: Re: Addition of two new actions > > > ... > > > > I still don't see a need for a SuccessAction in the first place. Why > > > is > > > > it any better than using a ForwardAction? > > > > > > I did expand on my reasons, but there's been a lot of traffic so maybe > > > it > > > scrolled by: > > > > > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] > arta.apach > > e.org&msgNo=19706 > > > > Erik's message also adds to this. > > > > Steve > > > > > > > > David > > > > > > > > > > > > > - > > 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]
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 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 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 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, > > > , 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]
RE: Addition of two new actions
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 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 or ForwardAction. How would adding it be bad for Struts? 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 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, > > , 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]
RE: Addition of two new actions
--- Steve Raeburn <[EMAIL PROTECTED]> wrote: > You're right 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, > , 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 > > > -Original Message- > > From: David Graham [mailto:[EMAIL PROTECTED] > > Sent: August 4, 2003 7:03 AM > > To: Struts Developers List > > Subject: RE: Addition of two new actions > > > > > > Thanks for the link. I'll respond to that message here: > > > > > I'm also throwing an exception if the "success" ActionForward is not > > found to make the configuration problem very clear. > > > > ForwardAction also throws an exception if the path is not found. > > > > > ForwardAction and using 'forward= ' on the ActionMapping both > require a > > > context relative path. > > > > That's not accurate, and both default to > > module relative paths. changes the > > default. ForwardAction itself always returns a context relative > > ActionForward but I'd rather see that changed than add a new class. > > > > > In addition, tools vendors may be better able to validate a regular > > > ActionFoward configuration than the ForwardAction where the path is > > > specified via the all-purpose 'parameter'. In order to validate the > path > > as > > > a parameter, you require knowledge of the Action class whereas the > path > > of > > > an ActionForward definition can be more easily validated. (I'm > basing > > this > > > on my experience with WebSphere Studio). > > > > There are many ways of defining forwards: > > > > > > > > > > > parameter="/jsp/input.jsp"/> > > > > Some of these allow better path validation than others but I don't see > why > > we need yet another Action class when we could just improve upon the > > existing options. > > > > David > > > > > Steve > > > > --- Steve Raeburn <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > > > From: David Graham [mailto:[EMAIL PROTECTED] > > > > Sent: August 3, 2003 3:02 PM > > > > To: Struts Developers List > > > > Subject: Re: Addition of two new actions > > > ... > > > > I still don't see a need for a SuccessAction in the first place. > Why > > > is > > > > it any better than using a ForwardAction? > > > > > > I did expand on my reasons, but there's been a lot of traffic so > maybe > > > it > > > scrolled by: > > > > > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] > arta.apach > > e.org&msgNo=19706 > > > > Erik's message also adds to this. > > > > Steve > > > > > > > > David > > > > > > > > > > > > > - > > 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]
RE: Addition of two new actions
In an ideal world, DispatchAction should probably become ParameterDispatchAction and this could be plain old DispatchAction. Is Anthony's original suggestion of ConfigDispatchAction any better? I can't think of a name that I *really* like so I'm +0 on Mapping or Config. Steve > -Original Message- > From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper > Sent: August 4, 2003 10:15 AM > To: [EMAIL PROTECTED] > Subject: Re: Addition of two new actions > > I'm +1 on this, other than on naming. I think ParameterDispatchAction is > definitely the wrong name for the last of these. People are *far* more > likely to think of the "Parameter" in the name as meaning a request > parameter than they are to think of the "parameter" action mapping > attribute. Perhaps MappingDispatchAction instead? > > I am -0 on combining all of this into one action. > > -- > Martin Cooper > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Addition of two new actions
You're right is module relative (despite what it says in the Javadoc). However, I don't see how it can used with a context relative path. There is no contextRelative attribute on the action config so you don't get to choose (or change) how your forward works. Of the three ways of defining forwards that you identified only one, , 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. Steve > -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: August 4, 2003 7:03 AM > To: Struts Developers List > Subject: RE: Addition of two new actions > > > Thanks for the link. I'll respond to that message here: > > > I'm also throwing an exception if the "success" ActionForward is not > found to make the configuration problem very clear. > > ForwardAction also throws an exception if the path is not found. > > > ForwardAction and using 'forward= ' on the ActionMapping both require a > > context relative path. > > That's not accurate, and both default to > module relative paths. changes the > default. ForwardAction itself always returns a context relative > ActionForward but I'd rather see that changed than add a new class. > > > In addition, tools vendors may be better able to validate a regular > > ActionFoward configuration than the ForwardAction where the path is > > specified via the all-purpose 'parameter'. In order to validate the path > as > > a parameter, you require knowledge of the Action class whereas the path > of > > an ActionForward definition can be more easily validated. (I'm basing > this > > on my experience with WebSphere Studio). > > There are many ways of defining forwards: > > > > > parameter="/jsp/input.jsp"/> > > Some of these allow better path validation than others but I don't see why > we need yet another Action class when we could just improve upon the > existing options. > > David > > > Steve > > --- Steve Raeburn <[EMAIL PROTECTED]> wrote: > > > -Original Message- > > > From: David Graham [mailto:[EMAIL PROTECTED] > > > Sent: August 3, 2003 3:02 PM > > > To: Struts Developers List > > > Subject: Re: Addition of two new actions > > ... > > > I still don't see a need for a SuccessAction in the first place. Why > > is > > > it any better than using a ForwardAction? > > > > I did expand on my reasons, but there's been a lot of traffic so maybe > > it > > scrolled by: > > > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] arta.apach > e.org&msgNo=19706 > > Erik's message also adds to this. > > Steve > > > > > David > > > > > > > - > 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]
Re: Addition of two new actions
At 10:16 -0700 8/4/03, Martin Cooper wrote: That sounds rather dangerous to me, unless you have some additional control over which JSP pages can be accessed in this way. From your description, it sounds like this gives the client blanket access to all the JSP pages in your app, which I certainly wouldn't want. I suppose it would, if they knew where the JSPs were. I thought about trying to integrate support for the "hide JSPs in /WEB-INF/" strategy, but since we use WL6 which doesn't permit that hiding, I decided to hold off. Can you elaborate on the danger, though? I mean, I don't like people poking around either, but I can't think of critical risks to which this exposes an application. And if you can't use WEB-INF hiding, I don't see how this is any riskier than normal -- it's not much difference whether the client guesses paths ending in .jsp or guesses at paths ending in .do, I don't think. As noted in another followup, the goal here is to make our HTML staff more self-sufficient. (Before long, we hope to have them on Mac OS X and trained in the rudiments of Struts config files and running a webapp with Ant, but we're not there yet.)Maybe our clients are just verbose, but the number of otherwise static pages we need to deal with makes a solution like this appealing. Thanks for any security advice, certainly. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
"Joe Germuska" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > At 19:29 -0400 8/3/03, Erik Hatcher wrote: > >Having a SuccessAction makes it much easier to do > >skeleton/storyboarded sites and fill in the details later. > >Switching from a SuccessAction to a real action when the time is > >right requires only changing the class name, not the structure of > >the action mapping XML too. In my Advanced Struts talks, I > >recommend a SuccessAction over ForwardAction as how I do it. Of > >course everyone's mileage may vary. > > Parallel to all of this, I've been cleaning up some docs and > preparing for another small release of the JGSI tools for Struts > (http://demo.jgsullivan.com/struts/). The only new class, actually, > is an action that also fits into this skeleton/storyboarding phase, > so I thought I'd mention it to folks. > > The class is called "SmartForwardingAction," and the idea is that you > don't even have to bother entering action mappings into struts-config > for this common case where you want to hide an essentially static > page behind an action (along the Struts Catalog strategy "Use a > forwarding Action for static pages." > > If you register "SmartForwardingAction" as your "unknown" (default) > action, it will take what would have been the action path, append > ".jsp", and forward to that JSP. So if someone requests > "/HelloWorld.do", the action looks for "/HelloWorld.jsp". If > getRequestDispatcher() for that path returns null, an exception is > thrown; otherwise, the execute method returns a ForwardingAction > pointing to that path. That sounds rather dangerous to me, unless you have some additional control over which JSP pages can be accessed in this way. From your description, it sounds like this gives the client blanket access to all the JSP pages in your app, which I certainly wouldn't want. -- Martin Cooper > > Actually, I'd been meaning to raise a question related to this to the > developers -- to achieve this, I copied the "processPath" method out > of the default RequestProcessor class. I was wondering if we might > agree on a request attribute under which that path could be passed > (i.e. Globals.ACTION_PATH_KEY) so that this action or any other > action mapped under "unknown='true'" would have access to it. It's > nothing huge, but it seems pretty safe. > > See http://demo.jgsullivan.com/struts/SmartForwardingAction.html for > a little more writeup. The class is in the 0.2-dev jar which can be > downloaded from the above site in binary or source form. I'm working > with Ted H. to get at least some of the JGSI struts tools into the > Source Forge project -- I mostly just wanted to finish this > documentation before putting it over there. > > The other change for this small release is the addition of a default > set of digester rules for creating a list of LabelValueBeans so that > you can configure select menus for your application in XML files -- > see http://demo.jgsullivan.com/struts/DigestingPlugIn_Example.html > > Cheers, > Joe > > -- > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "If nature worked that way, the universe would crash all the time." > --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
"Steve Raeburn" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > ParameterDispatchAction fulfils much the same function as > LookupDispatchAction but its implementation is almost identical to > DispatchAction. > > It would be redundant to go through getKeyMethodMap() to get the method name > because it is supplied in the parameter. I may have misunderstood what you > are suggesting but to me it would make more sense to add to DispatchAction > than to Lookup DispatchAction. > > It *may* make some sense to combine all three resolution methods into > DispatchAction and either have DispatchAction try to find a handler using > all three methods or set the method via a configuration parameter. > > I worry that that would be more confusing to the user that having three > distinct classes that you can explain quite simply: > > To dispatch to a method identified via a request parameter, use > DispatchAction. > To dispatch to a method based on which button was clicked, use > LookupDispatchAction > To dispatch to a method based on the action path, use > ParameterDispatchAction I'm +1 on this, other than on naming. I think ParameterDispatchAction is definitely the wrong name for the last of these. People are *far* more likely to think of the "Parameter" in the name as meaning a request parameter than they are to think of the "parameter" action mapping attribute. Perhaps MappingDispatchAction instead? I am -0 on combining all of this into one action. -- Martin Cooper > > I would prefer to add ParameterDispatchAction now and defer a decision about > merging the three actions. > To me, that would be 'the simplest thing that could possibly work' :-) > > Steve > > > > -Original Message- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > > Sent: August 1, 2003 10:42 AM > > To: Struts Developers List; [EMAIL PROTECTED] > > Subject: RE: Addition of two new actions > > > > > > So, what you really want is LookupDispatchAction without requiring the > > developer to create the map-related methods? I think you already get the > > abililty to combine CRUD related actions and things like that. If so, > > then implementing a default getKeyMethodMap() in LookupDispatchAction > > might accomplish the same goal, without requiring another action. Such a > > default implementation could examine the current LookupDispatchAction > > subclass and create the mapping information automatically. > > > > Don't get me wrong ... I like the idea behind what you're proposing. I > > just think we might already have it (with the potential to improve ease of > > use by not forcing people to implement getKeyMethodMap() for a common use > > case). > > > > > > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Addition of two new actions
Thanks for the link. I'll respond to that message here: > I'm also throwing an exception if the "success" ActionForward is not found to make the configuration problem very clear. ForwardAction also throws an exception if the path is not found. > ForwardAction and using 'forward= ' on the ActionMapping both require a > context relative path. That's not accurate, and both default to module relative paths. changes the default. ForwardAction itself always returns a context relative ActionForward but I'd rather see that changed than add a new class. > In addition, tools vendors may be better able to validate a regular > ActionFoward configuration than the ForwardAction where the path is > specified via the all-purpose 'parameter'. In order to validate the path as > a parameter, you require knowledge of the Action class whereas the path of > an ActionForward definition can be more easily validated. (I'm basing this > on my experience with WebSphere Studio). There are many ways of defining forwards: Some of these allow better path validation than others but I don't see why we need yet another Action class when we could just improve upon the existing options. David > Steve --- Steve Raeburn <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: David Graham [mailto:[EMAIL PROTECTED] > > Sent: August 3, 2003 3:02 PM > > To: Struts Developers List > > Subject: Re: Addition of two new actions > ... > > I still don't see a need for a SuccessAction in the first place. Why > is > > it any better than using a ForwardAction? > > I did expand on my reasons, but there's been a lot of traffic so maybe > it > scrolled by: > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] > e.org&msgNo=19706 > > Erik's message also adds to this. > > Steve > > > > > David > > > > > > > - > 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]
"SmartForwardingAction" (Re: Addition of two new actions)
At 3:56 -0400 8/4/03, Erik Hatcher wrote: The only issue that it would have for me though, is we use different naming conventions for action mappings than we do for JSP pages, so it would require we either change our conventions or just rename JSP's when we inject a real action in the middle at a later time. Yeah, I thought about trying to support more flexible translation, but this suits us. I figured I'd wait for someone with a more clear use case to describe it before trying to build that flexibility out. (Or for someone to submit a patch :-) Actually, although I brought it up in the context of storyboarding, we really came up with this mostly for the "static content" of a site. If there are pages that are predominantly text (policies, boiler plate, marketing...), this makes it easier to add them. Part of the goal is to empower our HTML staff to extend the site with "static" content without needing to reconfigure and restart the server. Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
On Sunday, August 3, 2003, at 10:05 PM, Joe Germuska wrote: If you register "SmartForwardingAction" as your "unknown" (default) action, it will take what would have been the action path, append ".jsp", and forward to that JSP. So if someone requests "/HelloWorld.do", the action looks for "/HelloWorld.jsp". If getRequestDispatcher() for that path returns null, an exception is thrown; otherwise, the execute method returns a ForwardingAction pointing to that path. Now that is pretty clever! Nice. The only issue that it would have for me though, is we use different naming conventions for action mappings than we do for JSP pages, so it would require we either change our conventions or just rename JSP's when we inject a real action in the middle at a later time. There still seems to be an advantage to keeping all .do links listed in struts-config though - at least then you can see all entry points of your app. in one place. Again, a nifty action though. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
On Sun, 3 Aug 2003, David Graham wrote: > Not everyone uses the terms "success" and "failure" in their apps and > hardcoding these into Struts is *not* a good idea. It's an extremely > small wheel to reinvent public static final String SUCCESS = "blah"; :-). It is a small wheel to reinvent, but a time saver for anyone ramping up on the learning curve. If you can make a small improvement like this so that someone can become productive faster and see fewer barriers to getting their app up without compromising struts architecture or vision, then so be it. Also, In regards to not everyone using the same name, perhaps that isn't a good thing, rather we should "standardize" the name so everyone is speaking the same language or atleast encouraged to do so. Making these static globals isn't locking anyone into using them. -Adam K. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
At 19:29 -0400 8/3/03, Erik Hatcher wrote: Having a SuccessAction makes it much easier to do skeleton/storyboarded sites and fill in the details later. Switching from a SuccessAction to a real action when the time is right requires only changing the class name, not the structure of the action mapping XML too. In my Advanced Struts talks, I recommend a SuccessAction over ForwardAction as how I do it. Of course everyone's mileage may vary. Parallel to all of this, I've been cleaning up some docs and preparing for another small release of the JGSI tools for Struts (http://demo.jgsullivan.com/struts/). The only new class, actually, is an action that also fits into this skeleton/storyboarding phase, so I thought I'd mention it to folks. The class is called "SmartForwardingAction," and the idea is that you don't even have to bother entering action mappings into struts-config for this common case where you want to hide an essentially static page behind an action (along the Struts Catalog strategy "Use a forwarding Action for static pages." If you register "SmartForwardingAction" as your "unknown" (default) action, it will take what would have been the action path, append ".jsp", and forward to that JSP. So if someone requests "/HelloWorld.do", the action looks for "/HelloWorld.jsp". If getRequestDispatcher() for that path returns null, an exception is thrown; otherwise, the execute method returns a ForwardingAction pointing to that path. Actually, I'd been meaning to raise a question related to this to the developers -- to achieve this, I copied the "processPath" method out of the default RequestProcessor class. I was wondering if we might agree on a request attribute under which that path could be passed (i.e. Globals.ACTION_PATH_KEY) so that this action or any other action mapped under "unknown='true'" would have access to it. It's nothing huge, but it seems pretty safe. See http://demo.jgsullivan.com/struts/SmartForwardingAction.html for a little more writeup. The class is in the 0.2-dev jar which can be downloaded from the above site in binary or source form. I'm working with Ted H. to get at least some of the JGSI struts tools into the Source Forge project -- I mostly just wanted to finish this documentation before putting it over there. The other change for this small release is the addition of a default set of digester rules for creating a list of LabelValueBeans so that you can configure select menus for your application in XML files -- see http://demo.jgsullivan.com/struts/DigestingPlugIn_Example.html Cheers, Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Addition of two new actions
I don't think that using a token provides any additional flexibility. The value "success" is still part of the public interface, even if you use a token, because it is used throughout the configuration files. And that's not a bad thing here, because there's not much point in having an action that forwards to a well-known name and then going and changing the name. (Would it even be a SuccessAction anymore?) If you did change the name, the effort involved is the same, whether you use a token or not. One line of java code (in either the Action or the constants class), plus all the action configurations that use the action. Using a token won't prevent the latter part of that change. The downside of using a token is that adding a level of indirection might just be enough to confuse someone who already has enough (necessary) complexity to deal with. If you still want to use a constant then I don't want to get hung up on it, but I think it is *marginally* better not to in this unusual case. Steve > -Original Message- > From: Ted Husted [mailto:[EMAIL PROTECTED] > Sent: August 3, 2003 2:07 PM > To: Struts Developers List > Subject: Re: Addition of two new actions > > > Steve Raeburn wrote: > > SuccessAction does already exist in Scaffold. That version is slightly > > different as it uses the Tokens constants class. I don't really see what > > that would buy us, as the user would still need to know what > name to enter > > for the ActionForward. I wouldn't want to tie a core Action to > the scaffold > > package and if we added the constant to Globals it just makes > it harder for > > the user to figure out what to name his ActionForward. (Imagine the > > Javadoc - "This action forwards to an ActionForward specified > by the value > > of the org.apache.struts.Globals.SUCCESS constant" vs. "This > action forwards > > to an ActionForward named "success".) > > Actually, I would say that we should provide "success" and "failure" as > standard tokens in the Global class. We are forever saying that most > Actions only need success and failure to make do. And, I for one, have > sworn off *ever* using a inline static String in production code. Rather > than expect everyone to reinvent the wheel by defining "success" and > "failure" in their own applications, we should just provide it as a > convenience. > > Of course, I realize that these are English words. But, so are "true" > and "false", and the Java platform defines these as String statics, and > we should feel free to do the same with "success" and "failure". > Virtually every Struts example program uses these tokens, and we should > just get real and make them globals. > > As for the JavaDoc issues, we already have to do this with everything > else, like what key attribute the locale property is stored under in the > session context. > > Meanwhile, if there is anything anyone wants to move or copy from > Scaffold to the core distribution, please feel free. =:) > > -Ted. > > > > > - > 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]
RE: Addition of two new actions
> -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: August 3, 2003 3:02 PM > To: Struts Developers List > Subject: Re: Addition of two new actions ... > I still don't see a need for a SuccessAction in the first place. Why is > it any better than using a ForwardAction? I did expand on my reasons, but there's been a lot of traffic so maybe it scrolled by: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] e.org&msgNo=19706 Erik's message also adds to this. Steve > > David > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
On Sunday, August 3, 2003, at 06:02 PM, David Graham wrote: Not everyone uses the terms "success" and "failure" in their apps and hardcoding these into Struts is *not* a good idea. It's an extremely small wheel to reinvent public static final String SUCCESS = "blah"; :-). Well, WebWork(2) defines them as constants for you. I use "success" and "failure" as my mapping names. Its a pretty standard thing. And so what if its defined in Struts? No one is forcing anyone to use it, but the primary defaults would be built-in as constants. I still don't see a need for a SuccessAction in the first place. Why is it any better than using a ForwardAction? Its a lot better in my opinion. Having to define a mapping in a parameter attribute doesn't sit well with me. I use inputForward="true" on my configuration, and all my forward mappings are defined with a element, not even in input, or parameter. Having a SuccessAction makes it much easier to do skeleton/storyboarded sites and fill in the details later. Switching from a SuccessAction to a real action when the time is right requires only changing the class name, not the structure of the action mapping XML too. In my Advanced Struts talks, I recommend a SuccessAction over ForwardAction as how I do it. Of course everyone's mileage may vary. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
--- Ted Husted <[EMAIL PROTECTED]> wrote: > Steve Raeburn wrote: > > SuccessAction does already exist in Scaffold. That version is slightly > > different as it uses the Tokens constants class. I don't really see > what > > that would buy us, as the user would still need to know what name to > enter > > for the ActionForward. I wouldn't want to tie a core Action to the > scaffold > > package and if we added the constant to Globals it just makes it > harder for > > the user to figure out what to name his ActionForward. (Imagine the > > Javadoc - "This action forwards to an ActionForward specified by the > value > > of the org.apache.struts.Globals.SUCCESS constant" vs. "This action > forwards > > to an ActionForward named "success".) > > Actually, I would say that we should provide "success" and "failure" as > standard tokens in the Global class. We are forever saying that most > Actions only need success and failure to make do. And, I for one, have > sworn off *ever* using a inline static String in production code. Rather > > than expect everyone to reinvent the wheel by defining "success" and > "failure" in their own applications, we should just provide it as a > convenience. Not everyone uses the terms "success" and "failure" in their apps and hardcoding these into Struts is *not* a good idea. It's an extremely small wheel to reinvent public static final String SUCCESS = "blah"; :-). I still don't see a need for a SuccessAction in the first place. Why is it any better than using a ForwardAction? David > > Of course, I realize that these are English words. But, so are "true" > and "false", and the Java platform defines these as String statics, and > we should feel free to do the same with "success" and "failure". > Virtually every Struts example program uses these tokens, and we should > just get real and make them globals. > > As for the JavaDoc issues, we already have to do this with everything > else, like what key attribute the locale property is stored under in the > > session context. > > Meanwhile, if there is anything anyone wants to move or copy from > Scaffold to the core distribution, please feel free. =:) > > -Ted. > > > > > - > 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]
Re: Addition of two new actions
Steve Raeburn wrote: SuccessAction does already exist in Scaffold. That version is slightly different as it uses the Tokens constants class. I don't really see what that would buy us, as the user would still need to know what name to enter for the ActionForward. I wouldn't want to tie a core Action to the scaffold package and if we added the constant to Globals it just makes it harder for the user to figure out what to name his ActionForward. (Imagine the Javadoc - "This action forwards to an ActionForward specified by the value of the org.apache.struts.Globals.SUCCESS constant" vs. "This action forwards to an ActionForward named "success".) Actually, I would say that we should provide "success" and "failure" as standard tokens in the Global class. We are forever saying that most Actions only need success and failure to make do. And, I for one, have sworn off *ever* using a inline static String in production code. Rather than expect everyone to reinvent the wheel by defining "success" and "failure" in their own applications, we should just provide it as a convenience. Of course, I realize that these are English words. But, so are "true" and "false", and the Java platform defines these as String statics, and we should feel free to do the same with "success" and "failure". Virtually every Struts example program uses these tokens, and we should just get real and make them globals. As for the JavaDoc issues, we already have to do this with everything else, like what key attribute the locale property is stored under in the session context. Meanwhile, if there is anything anyone wants to move or copy from Scaffold to the core distribution, please feel free. =:) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
Steve Raeburn said: > I would prefer going with simpler, specialised classes than a monolithic > DispatchAction but if there is a consensus to combine them then I accept > your point. > > A combined action may perhaps offer more flexibility. A concrete subclass > might be able to resolve the method in different ways depending on what was > present at runtime. (request parameter, parameter, key). i never liked the separate dispatch actions. so, i ended up writing one of these "combined" ones of my own. i think it's a good way to go. the flexibility allows me to extend all my actions from the one class and later worry about how the dispatch method is specified (via things that don't have to be re-compiled: struts-config, velocity templates, etc). > However, I'm not sure that flexibility justifies the increased complexity of > the class or of understanding how to use it. Potential areas for user > confusion would be misunderstanding the order of preference for resolving > the method names or not recognizing conflicts that could arise between them. yes, the order of precedence/preference would need to discussed and well documented/exampled. > Also, what happens if we need to resolve by other means? Add more weight to > the super class or add another specialized sub class? ... i don't think there's really that many reasonable ways to specify a dispatch, and you're just talking here about combining the various dispatch actions, right? Nathan Bubna [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
Steve Raeburn wrote: I would prefer going with simpler, specialised classes than a monolithic DispatchAction +1, I am infavor of the simpler classes. They are easier to understand, maintain and modify. but if there is a consensus to combine them then I accept your point. A combined action may perhaps offer more flexibility. A concrete subclass might be able to resolve the method in different ways depending on what was present at runtime. (request parameter, parameter, key). However, I'm not sure that flexibility justifies the increased complexity of the class or of understanding how to use it. Potential areas for user +1, I have see too many struts based programs heap the functionality into Action classes, and they are a bear to maintain. The same is true in any class, and having a simpler DispatchAction class is a cleaner way to go. confusion would be misunderstanding the order of preference for resolving the method names or not recognizing conflicts that could arise between them. Also, what happens if we need to resolve by other means? Add more weight to the super class or add another specialized sub class? To summarize: - I think we definitely need the functionality that ParameterDispatchAction offers. - If the actions are combined, the result needs to be just as extensible and easy to understand as keeping them separate. - I would rather not combine them, but I'm open to ideas that satisfy the previous two points. Steve Again, I am infavor of the simpler classes. - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
That could be a good compromise. A base action, that has 20% of code that is used by 80% of actions that extend it. (I am sure this suggestion is not needed: just writing a list of feaures, the figuring out what is in common to put in base vs specific. Ideally somehow tiles action could be extended from the "base" action.) My original objection was based on teaching Struts? Ex: When should we use tiles action? It is just easier to tell people, use this action, and pass in this type of arguments, and if it find nothing, it just defaults to "Success". .V Steve Raeburn wrote: I would prefer going with simpler, specialised classes than a monolithic DispatchAction but if there is a consensus to combine them then I accept your point. A combined action may perhaps offer more flexibility. A concrete subclass might be able to resolve the method in different ways depending on what was present at runtime. (request parameter, parameter, key). However, I'm not sure that flexibility justifies the increased complexity of the class or of understanding how to use it. Potential areas for user confusion would be misunderstanding the order of preference for resolving the method names or not recognizing conflicts that could arise between them. Also, what happens if we need to resolve by other means? Add more weight to the super class or add another specialized sub class? To summarize: - I think we definitely need the functionality that ParameterDispatchAction offers. - If the actions are combined, the result needs to be just as extensible and easy to understand as keeping them separate. - I would rather not combine them, but I'm open to ideas that satisfy the previous two points. Steve -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: August 1, 2003 1:38 PM To: Struts Developers List Subject: RE: Addition of two new actions I would prefer to add ParameterDispatchAction now and defer a decision about merging the three actions. To me, that would be 'the simplest thing that could possibly work' :-) The downside to doing that is if we decide to combine them we have to go through the deprecation phase, document the changes, and explain it to confused users. I'd prefer it if we took a look at all 3 classes now and decided on an implementation before committing anything new. David Steve -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: August 1, 2003 10:42 AM To: Struts Developers List; [EMAIL PROTECTED] Subject: RE: Addition of two new actions So, what you really want is LookupDispatchAction without requiring the developer to create the map-related methods? I think you already get the abililty to combine CRUD related actions and things like that. If so, then implementing a default getKeyMethodMap() in LookupDispatchAction might accomplish the same goal, without requiring another action. Such a default implementation could examine the current LookupDispatchAction subclass and create the mapping information automatically. Don't get me wrong ... I like the idea behind what you're proposing. I just think we might already have it (with the potential to improve ease of use by not forcing people to implement getKeyMethodMap() for a common use case). Craig - 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]
RE: Addition of two new actions
I would prefer going with simpler, specialised classes than a monolithic DispatchAction but if there is a consensus to combine them then I accept your point. A combined action may perhaps offer more flexibility. A concrete subclass might be able to resolve the method in different ways depending on what was present at runtime. (request parameter, parameter, key). However, I'm not sure that flexibility justifies the increased complexity of the class or of understanding how to use it. Potential areas for user confusion would be misunderstanding the order of preference for resolving the method names or not recognizing conflicts that could arise between them. Also, what happens if we need to resolve by other means? Add more weight to the super class or add another specialized sub class? To summarize: - I think we definitely need the functionality that ParameterDispatchAction offers. - If the actions are combined, the result needs to be just as extensible and easy to understand as keeping them separate. - I would rather not combine them, but I'm open to ideas that satisfy the previous two points. Steve > -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: August 1, 2003 1:38 PM > To: Struts Developers List > Subject: RE: Addition of two new actions > > > > I would prefer to add ParameterDispatchAction now and defer a decision > > about > > merging the three actions. > > To me, that would be 'the simplest thing that could possibly work' :-) > > The downside to doing that is if we decide to combine them we have to go > through the deprecation phase, document the changes, and explain it to > confused users. I'd prefer it if we took a look at all 3 classes now and > decided on an implementation before committing anything new. > > David > > > Steve > > > > > > > -Original Message- > > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > > > Sent: August 1, 2003 10:42 AM > > > To: Struts Developers List; [EMAIL PROTECTED] > > > Subject: RE: Addition of two new actions > > > > > > > > > So, what you really want is LookupDispatchAction without requiring the > > > developer to create the map-related methods? I think you already get > > the > > > abililty to combine CRUD related actions and things like that. If so, > > > then implementing a default getKeyMethodMap() in LookupDispatchAction > > > might accomplish the same goal, without requiring another action. > > Such a > > > default implementation could examine the current LookupDispatchAction > > > subclass and create the mapping information automatically. > > > > > > Don't get me wrong ... I like the idea behind what you're proposing. > > I > > > just think we might already have it (with the potential to improve > > ease of > > > use by not forcing people to implement getKeyMethodMap() for a common > > use > > > case). > > > > > > > > > Craig > > > > > > > > - > > 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]
Re: Addition of two new actions
Oops sorry. I sent this email to the wrong address. Greg Reddin wrote: I'm going through the process right now of building all the audio tools. I'm also documenting every step of it, and hope to publish it in some way when I get done. We'll see how it goes. Greg David Graham wrote: I would prefer to add ParameterDispatchAction now and defer a decision about merging the three actions. To me, that would be 'the simplest thing that could possibly work' :-) The downside to doing that is if we decide to combine them we have to go through the deprecation phase, document the changes, and explain it to confused users. I'd prefer it if we took a look at all 3 classes now and decided on an implementation before committing anything new. David Steve -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: August 1, 2003 10:42 AM To: Struts Developers List; [EMAIL PROTECTED] Subject: RE: Addition of two new actions So, what you really want is LookupDispatchAction without requiring the developer to create the map-related methods? I think you already get the abililty to combine CRUD related actions and things like that. If so, then implementing a default getKeyMethodMap() in LookupDispatchAction might accomplish the same goal, without requiring another action. Such a default implementation could examine the current LookupDispatchAction subclass and create the mapping information automatically. Don't get me wrong ... I like the idea behind what you're proposing. I just think we might already have it (with the potential to improve ease of use by not forcing people to implement getKeyMethodMap() for a common use case). Craig - 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] DISCLAIMER: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments. DISCLAIMER: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] DISCLAIMER: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments. DISCLAIMER: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
I'm going through the process right now of building all the audio tools. I'm also documenting every step of it, and hope to publish it in some way when I get done. We'll see how it goes. Greg David Graham wrote: I would prefer to add ParameterDispatchAction now and defer a decision about merging the three actions. To me, that would be 'the simplest thing that could possibly work' :-) The downside to doing that is if we decide to combine them we have to go through the deprecation phase, document the changes, and explain it to confused users. I'd prefer it if we took a look at all 3 classes now and decided on an implementation before committing anything new. David Steve -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: August 1, 2003 10:42 AM To: Struts Developers List; [EMAIL PROTECTED] Subject: RE: Addition of two new actions So, what you really want is LookupDispatchAction without requiring the developer to create the map-related methods? I think you already get the abililty to combine CRUD related actions and things like that. If so, then implementing a default getKeyMethodMap() in LookupDispatchAction might accomplish the same goal, without requiring another action. Such a default implementation could examine the current LookupDispatchAction subclass and create the mapping information automatically. Don't get me wrong ... I like the idea behind what you're proposing. I just think we might already have it (with the potential to improve ease of use by not forcing people to implement getKeyMethodMap() for a common use case). Craig - 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] DISCLAIMER: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments. DISCLAIMER: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Addition of two new actions
> I would prefer to add ParameterDispatchAction now and defer a decision > about > merging the three actions. > To me, that would be 'the simplest thing that could possibly work' :-) The downside to doing that is if we decide to combine them we have to go through the deprecation phase, document the changes, and explain it to confused users. I'd prefer it if we took a look at all 3 classes now and decided on an implementation before committing anything new. David > Steve > > > > -Original Message- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > > Sent: August 1, 2003 10:42 AM > > To: Struts Developers List; [EMAIL PROTECTED] > > Subject: RE: Addition of two new actions > > > > > > So, what you really want is LookupDispatchAction without requiring the > > developer to create the map-related methods? I think you already get > the > > abililty to combine CRUD related actions and things like that. If so, > > then implementing a default getKeyMethodMap() in LookupDispatchAction > > might accomplish the same goal, without requiring another action. > Such a > > default implementation could examine the current LookupDispatchAction > > subclass and create the mapping information automatically. > > > > Don't get me wrong ... I like the idea behind what you're proposing. > I > > just think we might already have it (with the potential to improve > ease of > > use by not forcing people to implement getKeyMethodMap() for a common > use > > case). > > > > > > Craig > > > > - > 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]
RE: Addition of two new actions
ParameterDispatchAction fulfils much the same function as LookupDispatchAction but its implementation is almost identical to DispatchAction. It would be redundant to go through getKeyMethodMap() to get the method name because it is supplied in the parameter. I may have misunderstood what you are suggesting but to me it would make more sense to add to DispatchAction than to Lookup DispatchAction. It *may* make some sense to combine all three resolution methods into DispatchAction and either have DispatchAction try to find a handler using all three methods or set the method via a configuration parameter. I worry that that would be more confusing to the user that having three distinct classes that you can explain quite simply: To dispatch to a method identified via a request parameter, use DispatchAction. To dispatch to a method based on which button was clicked, use LookupDispatchAction To dispatch to a method based on the action path, use ParameterDispatchAction I would prefer to add ParameterDispatchAction now and defer a decision about merging the three actions. To me, that would be 'the simplest thing that could possibly work' :-) Steve > -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: August 1, 2003 10:42 AM > To: Struts Developers List; [EMAIL PROTECTED] > Subject: RE: Addition of two new actions > > > So, what you really want is LookupDispatchAction without requiring the > developer to create the map-related methods? I think you already get the > abililty to combine CRUD related actions and things like that. If so, > then implementing a default getKeyMethodMap() in LookupDispatchAction > might accomplish the same goal, without requiring another action. Such a > default implementation could examine the current LookupDispatchAction > subclass and create the mapping information automatically. > > Don't get me wrong ... I like the idea behind what you're proposing. I > just think we might already have it (with the potential to improve ease of > use by not forcing people to implement getKeyMethodMap() for a common use > case). > > > Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
--- Rob Leland <[EMAIL PROTECTED]> wrote: > David Graham wrote: > > >>>I have a few concerns with this. First, it's more work to maintain > >>> > >>> > >>this > >> > >> > >>>new optional package with build files, tests, distribution, etc. > >>> > >>> > >>Second, > >> > >> > >>>it's likely that the unused code would decay because Struts isn't > using > >>>it. > >>> > >>> > >>> > >>Since we don't currently have a struts-contrib or struts-tools > >>distribution I would agree. > >>Once that is in place I believe that would change. > >> > >> > >> > >>>Also, it's confusing to have some actions in o.a.s.tools.actions and > >>>some in o.a.s.actions. I think *all* standard actions that are > >>>distributed with Struts should live in o.a.s.actions. > >>> > >>> > >>> > >>or moved into the tools jar. I agree with what you said : > >>"I think unused methods/classes should be deprecated and removed." > >> > >>If the struts core doesn't use it then it doesn't belong in the core, > >>and should be > >>moved to a seperate jar. That includes any actions > >> > >> > > > > > >So you're proposing that all of the current actions be separated from > the > >standard Struts distro jar? > > > Yes, and if it is documented and deprecated over enough time, then by > struts 1.4 they could be removed. > It's one way to get a lean struts-core. How do we make a distinction > between the 'actions' classes and come other > methods()/classes say under the util package about which stays and > which goes. Whats the reasoning ? I'm viewing RequestUtils as a place to put common methods used by internal Struts code. IMO, when Struts stops using its utility methods, those methods should go away or they will decay and be a source of bugs. The standard actions, however, are used by developers to build a Struts app so it makes sense to package it with the Struts core. David > > > I think that will be highly confusing. > > > > > No more so than going from struts 1.0 -> 1.1 where the import > statements changed for BeanUtils had to change. > And much less confusing than pulling out the TagUtil from > RequestUtils, which requires changing imports and code, > instead of just the import statements. > > > > >> > >> > >>Choose a job you love, and you will never have to work a day of your > >>life. > >> > > >> -Confucius. > >> > >> > >> > >> > > > > > >__ > >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] > > > > > > > > > > > > > -- > - > Rob Leland (703-525-3580) > > > Choose a job you love, and you will never have to work a day of your > life. > > -Confucius. > > __ 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]
Re: Addition of two new actions
David Graham wrote: I have a few concerns with this. First, it's more work to maintain this new optional package with build files, tests, distribution, etc. Second, it's likely that the unused code would decay because Struts isn't using it. Since we don't currently have a struts-contrib or struts-tools distribution I would agree. Once that is in place I believe that would change. Also, it's confusing to have some actions in o.a.s.tools.actions and some in o.a.s.actions. I think *all* standard actions that are distributed with Struts should live in o.a.s.actions. or moved into the tools jar. I agree with what you said : "I think unused methods/classes should be deprecated and removed." If the struts core doesn't use it then it doesn't belong in the core, and should be moved to a seperate jar. That includes any actions So you're proposing that all of the current actions be separated from the standard Struts distro jar? Yes, and if it is documented and deprecated over enough time, then by struts 1.4 they could be removed. It's one way to get a lean struts-core. How do we make a distinction between the 'actions' classes and come other methods()/classes say under the util package about which stays and which goes. Whats the reasoning ? I think that will be highly confusing. No more so than going from struts 1.0 -> 1.1 where the import statements changed for BeanUtils had to change. And much less confusing than pulling out the TagUtil from RequestUtils, which requires changing imports and code, instead of just the import statements. Choose a job you love, and you will never have to work a day of your life. -Confucius. __ 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] -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius.
Re: Addition of two new actions
> >I have a few concerns with this. First, it's more work to maintain > this > >new optional package with build files, tests, distribution, etc. > Second, > >it's likely that the unused code would decay because Struts isn't using > >it. > > > Since we don't currently have a struts-contrib or struts-tools > distribution I would agree. > Once that is in place I believe that would change. > > >Also, it's confusing to have some actions in o.a.s.tools.actions and > >some in o.a.s.actions. I think *all* standard actions that are > >distributed with Struts should live in o.a.s.actions. > > > or moved into the tools jar. I agree with what you said : > "I think unused methods/classes should be deprecated and removed." > > If the struts core doesn't use it then it doesn't belong in the core, > and should be > moved to a seperate jar. That includes any actions So you're proposing that all of the current actions be separated from the standard Struts distro jar? I think that will be highly confusing. David > > > > >David > > > > > -- > - > Rob Leland (703-525-3580) > > > Choose a job you love, and you will never have to work a day of your > life. > > -Confucius. > > __ 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]
RE: Addition of two new actions
On Fri, 1 Aug 2003, Steve Raeburn wrote:
> Date: Fri, 1 Aug 2003 10:01:35 -0700
> From: Steve Raeburn <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: Addition of two new actions
>
> ParameterDispatchAction resolves the method directly from the value of the
> parameter. parameter="add" would look for a method in the user's subclass
> named 'add'.
>
> Unlike DispatchAction, the various action definitions do not need to share
> the same attributes. Each action is defined separately with its own path,
> form, validation etc.
>
> For example, you could combine all the CRUD related actions for a business
> object into a single action class to better organize and encapsulate code,
> but still be able to validate forms in some actions but not in others.
>
> I don't see any technical reason why this couldn't be combined with
> DispatchAction but it feels like cramming too much in to a single class to
> me. (There's already a request in Bugzilla to combine LookupDispatchAction
> with DispatchAction). I prefer that each class do one thing and do it well
> rather than try to shoehorn several different resolution methods into a
> single class.
>
So, what you really want is LookupDispatchAction without requiring the
developer to create the map-related methods? I think you already get the
abililty to combine CRUD related actions and things like that. If so,
then implementing a default getKeyMethodMap() in LookupDispatchAction
might accomplish the same goal, without requiring another action. Such a
default implementation could examine the current LookupDispatchAction
subclass and create the mapping information automatically.
Don't get me wrong ... I like the idea behind what you're proposing. I
just think we might already have it (with the potential to improve ease of
use by not forcing people to implement getKeyMethodMap() for a common use
case).
> Steve
Craig
>
> > -Original Message-
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> > Sent: August 1, 2003 9:01 AM
> > To: Struts Developers List; [EMAIL PROTECTED]
> > Subject: Re: Addition of two new actions
> >
> >
> >
> >
> > On Thu, 31 Jul 2003, Steve Raeburn wrote:
> >
> > > Date: Thu, 31 Jul 2003 23:10:59 -0700
> > > From: Steve Raeburn <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > > [EMAIL PROTECTED]
> > > To: Struts Developers List <[EMAIL PROTECTED]>
> > > Subject: Addition of two new actions
> > >
> > > I'd like to add two new actions to org.apache.struts.actions that I find
> > > particularly useful.
> > >
> > > 1. SuccessAction - A simple action that forwards control to an
> > ActionFoward
> > > named "success".
> > >
> > > This is a very simple action, but I find it exceptionally useful,
> > > particularly in the early stages of development when it can act as a
> > > placeholder for as-yet undeveloped actions.
> > >
> > > public ActionForward execute(
> > > ActionMapping mapping,
> > > ActionForm form,
> > > HttpServletRequest request,
> > > HttpServletResponse response)
> > > throws Exception {
> > >
> > > ActionForward forward = mapping.findForward("success");
> > > if (forward == null) {
> > > String message =
> > > messages.getMessage("success.required", mapping.getPath());
> > > log.error(message);
> > > throw new ServletException(message);
> > > }
> > > return forward;
> > > }
> > >
> >
> > I agree with others in the thread pointing out that this would be
> > redundant.
> >
> > > 2. ParameterDispatchAction - A DispatchAction that selects a
> > handler method
> > > using the value of the ActionMapping parameter.
> > >
> > > This is as per the suggestion by Anthony Kay via Bugzilla
> > > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17117>,
> > except I prefer
> > > the name ParameterDispatchAction to his suggestion of
> > ConfigDispatchAction
> > > as I think it's more descriptive of what the class actually
> > does. Other than
> > > the name change, I've just tidied up the Javadoc and changed the
> > > 'unspecified' method to throw an Exception (as in Dispat
Re: Addition of two new actions
David Graham wrote: --- Rob Leland <[EMAIL PROTECTED]> wrote: David Graham wrote: --- Rob Leland <[EMAIL PROTECTED]> wrote: Ted Husted wrote: I use many utilities Actions like these, and the result is that fewer *custom* Actions are needed. I think increasing the number of standard Actions in the distribution is a very good idea. It makes Struts more accessible to newcomers, saves everyone from reimplementing the same design, and leverages the fact that Actions are singletons. -Ted. How about struts-tools distribution named after the velocity-tools. These would be classes that could be used stand-alone or in pairs. Tnen we could place those orphan RequestUtils absoluteURL, and other utilities there. It would have a package structure o.a.s.tools.(util, actions, ) I think unused methods/classes should be deprecated and removed. We shouldn't be carrying around excess unused utility code just because a user *might* be using them. I agree they should be moved from the core package. And moved to an optional package. I have a few concerns with this. First, it's more work to maintain this new optional package with build files, tests, distribution, etc. Second, it's likely that the unused code would decay because Struts isn't using it. Since we don't currently have a struts-contrib or struts-tools distribution I would agree. Once that is in place I believe that would change. Also, it's confusing to have some actions in o.a.s.tools.actions and some in o.a.s.actions. I think *all* standard actions that are distributed with Struts should live in o.a.s.actions. or moved into the tools jar. I agree with what you said : "I think unused methods/classes should be deprecated and removed." If the struts core doesn't use it then it doesn't belong in the core, and should be moved to a seperate jar. That includes any actions David -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius.
Re: Addition of two new actions
--- Rob Leland <[EMAIL PROTECTED]> wrote: > David Graham wrote: > > >--- Rob Leland <[EMAIL PROTECTED]> wrote: > > > > > >>Ted Husted wrote: > >> > >> > >> > >>>I use many utilities Actions like these, and the result is that fewer > > >>>*custom* Actions are needed. I think increasing the number of > standard > >>> > >>> > >>>Actions in the distribution is a very good idea. It makes Struts more > > >>>accessible to newcomers, saves everyone from reimplementing the same > >>>design, and leverages the fact that Actions are singletons. > >>> > >>>-Ted. > >>> > >>> > >>How about struts-tools distribution named after the velocity-tools. > >>These would be classes that could be used stand-alone or in pairs. > >>Tnen we could place those orphan RequestUtils absoluteURL, and other > >>utilities there. > >>It would have a package structure o.a.s.tools.(util, actions, ) > >> > >> > > > >I think unused methods/classes should be deprecated and removed. We > >shouldn't be carrying around excess unused utility code just because a > >user *might* be using them. > > > > > I agree they should be moved from the core package. > And moved to an optional package. I have a few concerns with this. First, it's more work to maintain this new optional package with build files, tests, distribution, etc. Second, it's likely that the unused code would decay because Struts isn't using it. Also, it's confusing to have some actions in o.a.s.tools.actions and some in o.a.s.actions. I think *all* standard actions that are distributed with Struts should live in o.a.s.actions. David > > > > -- > - > Rob Leland (703-525-3580) > > > Choose a job you love, and you will never have to work a day of your > life. > > -Confucius. > > > > - > 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]
Re: Addition of two new actions
David Graham wrote: --- Rob Leland <[EMAIL PROTECTED]> wrote: Ted Husted wrote: I use many utilities Actions like these, and the result is that fewer *custom* Actions are needed. I think increasing the number of standard Actions in the distribution is a very good idea. It makes Struts more accessible to newcomers, saves everyone from reimplementing the same design, and leverages the fact that Actions are singletons. -Ted. How about struts-tools distribution named after the velocity-tools. These would be classes that could be used stand-alone or in pairs. Tnen we could place those orphan RequestUtils absoluteURL, and other utilities there. It would have a package structure o.a.s.tools.(util, actions, ) I think unused methods/classes should be deprecated and removed. We shouldn't be carrying around excess unused utility code just because a user *might* be using them. I agree they should be moved from the core package. And moved to an optional package. -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Addition of two new actions
ParameterDispatchAction resolves the method directly from the value of the
parameter. parameter="add" would look for a method in the user's subclass
named 'add'.
Unlike DispatchAction, the various action definitions do not need to share
the same attributes. Each action is defined separately with its own path,
form, validation etc.
For example, you could combine all the CRUD related actions for a business
object into a single action class to better organize and encapsulate code,
but still be able to validate forms in some actions but not in others.
I don't see any technical reason why this couldn't be combined with
DispatchAction but it feels like cramming too much in to a single class to
me. (There's already a request in Bugzilla to combine LookupDispatchAction
with DispatchAction). I prefer that each class do one thing and do it well
rather than try to shoehorn several different resolution methods into a
single class.
Steve
> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> Sent: August 1, 2003 9:01 AM
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: Re: Addition of two new actions
>
>
>
>
> On Thu, 31 Jul 2003, Steve Raeburn wrote:
>
> > Date: Thu, 31 Jul 2003 23:10:59 -0700
> > From: Steve Raeburn <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED]
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: Addition of two new actions
> >
> > I'd like to add two new actions to org.apache.struts.actions that I find
> > particularly useful.
> >
> > 1. SuccessAction - A simple action that forwards control to an
> ActionFoward
> > named "success".
> >
> > This is a very simple action, but I find it exceptionally useful,
> > particularly in the early stages of development when it can act as a
> > placeholder for as-yet undeveloped actions.
> >
> > public ActionForward execute(
> > ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response)
> > throws Exception {
> >
> > ActionForward forward = mapping.findForward("success");
> > if (forward == null) {
> > String message =
> > messages.getMessage("success.required", mapping.getPath());
> > log.error(message);
> > throw new ServletException(message);
> > }
> > return forward;
> > }
> >
>
> I agree with others in the thread pointing out that this would be
> redundant.
>
> > 2. ParameterDispatchAction - A DispatchAction that selects a
> handler method
> > using the value of the ActionMapping parameter.
> >
> > This is as per the suggestion by Anthony Kay via Bugzilla
> > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17117>,
> except I prefer
> > the name ParameterDispatchAction to his suggestion of
> ConfigDispatchAction
> > as I think it's more descriptive of what the class actually
> does. Other than
> > the name change, I've just tidied up the Javadoc and changed the
> > 'unspecified' method to throw an Exception (as in DispatchAction) rather
> > than return an Http error code.
> >
> > If no one has any problems with adding these two, I'll put them
> in tomorrow.
>
> Could you help me understand how this is different from what
> DispatchAction already does, or why we couldn't just update DispatchAction
> itself to add any additional functionality it represents?
>
> >
> >
> > Steve
>
> Craig
>
> -
> 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]
RE: Addition of two new actions
SuccessAction does already exist in Scaffold. That version is slightly
different as it uses the Tokens constants class. I don't really see what
that would buy us, as the user would still need to know what name to enter
for the ActionForward. I wouldn't want to tie a core Action to the scaffold
package and if we added the constant to Globals it just makes it harder for
the user to figure out what to name his ActionForward. (Imagine the
Javadoc - "This action forwards to an ActionForward specified by the value
of the org.apache.struts.Globals.SUCCESS constant" vs. "This action forwards
to an ActionForward named "success".)
I'm also throwing an exception if the "success" ActionForward is not found
to make the configuration problem very clear.
ForwardAction and using 'forward= ' on the ActionMapping both require a
context relative path. SuccessAction adds flexibility by allowing you to
specify the ActionForward in the normal way, including using module or
context relative paths.
In addition, tools vendors may be better able to validate a regular
ActionFoward configuration than the ForwardAction where the path is
specified via the all-purpose 'parameter'. In order to validate the path as
a parameter, you require knowledge of the Action class whereas the path of
an ActionForward definition can be more easily validated. (I'm basing this
on my experience with WebSphere Studio).
I did consider suggesting that FowardAction be deprecated in favour of
SuccessAction, because its function would be encompassed by the new action.
I held off because I thought that might be controversial :-)
I hope this better explains some of the reasons why I prefer SuccessAction
to the alternatives. I apologize for not explaining myself more fully in the
first place.
Steve
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper
> Sent: August 1, 2003 8:32 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Addition of two new actions
>
>
>
> "Steve Raeburn" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > I'd like to add two new actions to org.apache.struts.actions that I find
> > particularly useful.
> >
> > 1. SuccessAction - A simple action that forwards control to an
> ActionFoward
> > named "success".
>
> This already exists, in contrib:
>
> org.apache.struts.scaffold.SuccessAction
>
> or, as David pointed out, you could use ForwardAction instead.
>
> --
> Martin Cooper
>
>
> >
> > This is a very simple action, but I find it exceptionally useful,
> > particularly in the early stages of development when it can act as a
> > placeholder for as-yet undeveloped actions.
> >
> > public ActionForward execute(
> > ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response)
> > throws Exception {
> >
> > ActionForward forward = mapping.findForward("success");
> > if (forward == null) {
> > String message =
> > messages.getMessage("success.required", mapping.getPath());
> > log.error(message);
> > throw new ServletException(message);
> > }
> > return forward;
> > }
> >
> > 2. ParameterDispatchAction - A DispatchAction that selects a handler
> method
> > using the value of the ActionMapping parameter.
> >
> > This is as per the suggestion by Anthony Kay via Bugzilla
> > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17117>,
> except I prefer
> > the name ParameterDispatchAction to his suggestion of
> ConfigDispatchAction
> > as I think it's more descriptive of what the class actually does. Other
> than
> > the name change, I've just tidied up the Javadoc and changed the
> > 'unspecified' method to throw an Exception (as in DispatchAction) rather
> > than return an Http error code.
> >
> > If no one has any problems with adding these two, I'll put them in
> tomorrow.
> >
> >
> > Steve
>
>
>
>
> -
> 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]
Re: Addition of two new actions
--- Rob Leland <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > > I use many utilities Actions like these, and the result is that fewer > > *custom* Actions are needed. I think increasing the number of standard > > > Actions in the distribution is a very good idea. It makes Struts more > > accessible to newcomers, saves everyone from reimplementing the same > > design, and leverages the fact that Actions are singletons. > > > > -Ted. > > > How about struts-tools distribution named after the velocity-tools. > These would be classes that could be used stand-alone or in pairs. > Tnen we could place those orphan RequestUtils absoluteURL, and other > utilities there. > It would have a package structure o.a.s.tools.(util, actions, ) I think unused methods/classes should be deprecated and removed. We shouldn't be carrying around excess unused utility code just because a user *might* be using them. David > > > > -- > - > Rob Leland (703-525-3580) > > > Choose a job you love, and you will never have to work a day of your > life. > > -Confucius. > > > > - > 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]
Re: Addition of two new actions
Ted Husted wrote: I use many utilities Actions like these, and the result is that fewer *custom* Actions are needed. I think increasing the number of standard Actions in the distribution is a very good idea. It makes Struts more accessible to newcomers, saves everyone from reimplementing the same design, and leverages the fact that Actions are singletons. -Ted. How about struts-tools distribution named after the velocity-tools. These would be classes that could be used stand-alone or in pairs. Tnen we could place those orphan RequestUtils absoluteURL, and other utilities there. It would have a package structure o.a.s.tools.(util, actions, ) -- - Rob Leland (703-525-3580) Choose a job you love, and you will never have to work a day of your life. -Confucius. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
On Thu, 31 Jul 2003, Steve Raeburn wrote:
> Date: Thu, 31 Jul 2003 23:10:59 -0700
> From: Steve Raeburn <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Addition of two new actions
>
> I'd like to add two new actions to org.apache.struts.actions that I find
> particularly useful.
>
> 1. SuccessAction - A simple action that forwards control to an ActionFoward
> named "success".
>
> This is a very simple action, but I find it exceptionally useful,
> particularly in the early stages of development when it can act as a
> placeholder for as-yet undeveloped actions.
>
> public ActionForward execute(
> ActionMapping mapping,
> ActionForm form,
> HttpServletRequest request,
> HttpServletResponse response)
> throws Exception {
>
> ActionForward forward = mapping.findForward("success");
> if (forward == null) {
> String message =
> messages.getMessage("success.required", mapping.getPath());
> log.error(message);
> throw new ServletException(message);
> }
> return forward;
> }
>
I agree with others in the thread pointing out that this would be
redundant.
> 2. ParameterDispatchAction - A DispatchAction that selects a handler method
> using the value of the ActionMapping parameter.
>
> This is as per the suggestion by Anthony Kay via Bugzilla
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17117>, except I prefer
> the name ParameterDispatchAction to his suggestion of ConfigDispatchAction
> as I think it's more descriptive of what the class actually does. Other than
> the name change, I've just tidied up the Javadoc and changed the
> 'unspecified' method to throw an Exception (as in DispatchAction) rather
> than return an Http error code.
>
> If no one has any problems with adding these two, I'll put them in tomorrow.
Could you help me understand how this is different from what
DispatchAction already does, or why we couldn't just update DispatchAction
itself to add any additional functionality it represents?
>
>
> Steve
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
"Steve Raeburn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'd like to add two new actions to org.apache.struts.actions that I find
> particularly useful.
>
> 1. SuccessAction - A simple action that forwards control to an
ActionFoward
> named "success".
This already exists, in contrib:
org.apache.struts.scaffold.SuccessAction
or, as David pointed out, you could use ForwardAction instead.
--
Martin Cooper
>
> This is a very simple action, but I find it exceptionally useful,
> particularly in the early stages of development when it can act as a
> placeholder for as-yet undeveloped actions.
>
> public ActionForward execute(
> ActionMapping mapping,
> ActionForm form,
> HttpServletRequest request,
> HttpServletResponse response)
> throws Exception {
>
> ActionForward forward = mapping.findForward("success");
> if (forward == null) {
> String message =
> messages.getMessage("success.required", mapping.getPath());
> log.error(message);
> throw new ServletException(message);
> }
> return forward;
> }
>
> 2. ParameterDispatchAction - A DispatchAction that selects a handler
method
> using the value of the ActionMapping parameter.
>
> This is as per the suggestion by Anthony Kay via Bugzilla
> , except I prefer
> the name ParameterDispatchAction to his suggestion of ConfigDispatchAction
> as I think it's more descriptive of what the class actually does. Other
than
> the name change, I've just tidied up the Javadoc and changed the
> 'unspecified' method to throw an Exception (as in DispatchAction) rather
> than return an Http error code.
>
> If no one has any problems with adding these two, I'll put them in
tomorrow.
>
>
> Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
On Fri, 2003-08-01 at 10:21, David Graham wrote:
> --- Benjamin Tomasini <[EMAIL PROTECTED]> wrote:
> > To the end of making it accessible to newcomers, what about making a
> > "samples" directory for actions? Maybe even forms?
>
> That type of thing doesn't belong in the Struts core code, it belongs in
> the sample applications.
>
> David
Of course...
./src/share
./src/samples <-- here
Having it out of the wars will make it more accessible to users. I know
there are many ways of distributing samples. In the wars, Struts
project at sf.net, Ted has his own university projects.
Perhaps putting sample actions into the user guide, the making a
separate samples directory, would be nice.
Just some ideas.
Ben
>
> >
> > On Fri, 2003-08-01 at 06:19, Ted Husted wrote:
> > > I use many utilities Actions like these, and the result is that fewer
> > > *custom* Actions are needed. I think increasing the number of standard
> >
> > > Actions in the distribution is a very good idea. It makes Struts more
> > > accessible to newcomers, saves everyone from reimplementing the same
> > > design, and leverages the fact that Actions are singletons.
> > >
> > > -Ted.
> > >
> > > Vic Cekvenich wrote:
> > > > I think less actions are needed, not more.
> > > > .V
> > > >
> > > > Steve Raeburn wrote:
> > > >
> > > >> I'd like to add two new actions to org.apache.struts.actions that I
> > find
> > > >> particularly useful.
> > > >>
> > > >> 1. SuccessAction - A simple action that forwards control to an
> > > >> ActionFoward
> > > >> named "success".
> > > >>
> > > >> This is a very simple action, but I find it exceptionally useful,
> > > >> particularly in the early stages of development when it can act as
> > a
> > > >> placeholder for as-yet undeveloped actions.
> > > >>
> > > >> public ActionForward execute(
> > > >> ActionMapping mapping,
> > > >> ActionForm form,
> > > >> HttpServletRequest request,
> > > >> HttpServletResponse response)
> > > >> throws Exception {
> > > >>
> > > >> ActionForward forward = mapping.findForward("success");
> > > >> if (forward == null) {
> > > >> String message =
> > > >> messages.getMessage("success.required",
> > mapping.getPath());
> > > >> log.error(message);
> > > >> throw new ServletException(message);
> > > >> }
> > > >> return forward;
> > > >> }
> > > >>
> > > >> 2. ParameterDispatchAction - A DispatchAction that selects a
> > handler
> > > >> method
> > > >> using the value of the ActionMapping parameter.
> > > >>
> > > >> This is as per the suggestion by Anthony Kay via Bugzilla
> > > >> , except I
> >
> > > >> prefer
> > > >> the name ParameterDispatchAction to his suggestion of
> > > >> ConfigDispatchAction
> > > >> as I think it's more descriptive of what the class actually does.
> > > >> Other than
> > > >> the name change, I've just tidied up the Javadoc and changed the
> > > >> 'unspecified' method to throw an Exception (as in DispatchAction)
> > rather
> > > >> than return an Http error code.
> > > >>
> > > >> If no one has any problems with adding these two, I'll put them in
> > > >> tomorrow.
> > > >>
> > > >>
> > > >> Steve
> > > >
> > > >
> > > >
> > > >
> > > >
> > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > --
> > Benjamin Tomasini <[EMAIL PROTECTED]>
> > NetEverything, Inc.
> >
> >
> > -
> > 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]
--
Benjamin Tomasini <[EMAIL PROTECTED]>
NetEverything, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
--- Benjamin Tomasini <[EMAIL PROTECTED]> wrote:
> To the end of making it accessible to newcomers, what about making a
> "samples" directory for actions? Maybe even forms?
That type of thing doesn't belong in the Struts core code, it belongs in
the sample applications.
David
>
> On Fri, 2003-08-01 at 06:19, Ted Husted wrote:
> > I use many utilities Actions like these, and the result is that fewer
> > *custom* Actions are needed. I think increasing the number of standard
>
> > Actions in the distribution is a very good idea. It makes Struts more
> > accessible to newcomers, saves everyone from reimplementing the same
> > design, and leverages the fact that Actions are singletons.
> >
> > -Ted.
> >
> > Vic Cekvenich wrote:
> > > I think less actions are needed, not more.
> > > .V
> > >
> > > Steve Raeburn wrote:
> > >
> > >> I'd like to add two new actions to org.apache.struts.actions that I
> find
> > >> particularly useful.
> > >>
> > >> 1. SuccessAction - A simple action that forwards control to an
> > >> ActionFoward
> > >> named "success".
> > >>
> > >> This is a very simple action, but I find it exceptionally useful,
> > >> particularly in the early stages of development when it can act as
> a
> > >> placeholder for as-yet undeveloped actions.
> > >>
> > >> public ActionForward execute(
> > >> ActionMapping mapping,
> > >> ActionForm form,
> > >> HttpServletRequest request,
> > >> HttpServletResponse response)
> > >> throws Exception {
> > >>
> > >> ActionForward forward = mapping.findForward("success");
> > >> if (forward == null) {
> > >> String message =
> > >> messages.getMessage("success.required",
> mapping.getPath());
> > >> log.error(message);
> > >> throw new ServletException(message);
> > >> }
> > >> return forward;
> > >> }
> > >>
> > >> 2. ParameterDispatchAction - A DispatchAction that selects a
> handler
> > >> method
> > >> using the value of the ActionMapping parameter.
> > >>
> > >> This is as per the suggestion by Anthony Kay via Bugzilla
> > >> , except I
>
> > >> prefer
> > >> the name ParameterDispatchAction to his suggestion of
> > >> ConfigDispatchAction
> > >> as I think it's more descriptive of what the class actually does.
> > >> Other than
> > >> the name change, I've just tidied up the Javadoc and changed the
> > >> 'unspecified' method to throw an Exception (as in DispatchAction)
> rather
> > >> than return an Http error code.
> > >>
> > >> If no one has any problems with adding these two, I'll put them in
> > >> tomorrow.
> > >>
> > >>
> > >> Steve
> > >
> > >
> > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> --
> Benjamin Tomasini <[EMAIL PROTECTED]>
> NetEverything, Inc.
>
>
> -
> 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]
Re: Addition of two new actions
To the end of making it accessible to newcomers, what about making a
"samples" directory for actions? Maybe even forms?
On Fri, 2003-08-01 at 06:19, Ted Husted wrote:
> I use many utilities Actions like these, and the result is that fewer
> *custom* Actions are needed. I think increasing the number of standard
> Actions in the distribution is a very good idea. It makes Struts more
> accessible to newcomers, saves everyone from reimplementing the same
> design, and leverages the fact that Actions are singletons.
>
> -Ted.
>
> Vic Cekvenich wrote:
> > I think less actions are needed, not more.
> > .V
> >
> > Steve Raeburn wrote:
> >
> >> I'd like to add two new actions to org.apache.struts.actions that I find
> >> particularly useful.
> >>
> >> 1. SuccessAction - A simple action that forwards control to an
> >> ActionFoward
> >> named "success".
> >>
> >> This is a very simple action, but I find it exceptionally useful,
> >> particularly in the early stages of development when it can act as a
> >> placeholder for as-yet undeveloped actions.
> >>
> >> public ActionForward execute(
> >> ActionMapping mapping,
> >> ActionForm form,
> >> HttpServletRequest request,
> >> HttpServletResponse response)
> >> throws Exception {
> >>
> >> ActionForward forward = mapping.findForward("success");
> >> if (forward == null) {
> >> String message =
> >> messages.getMessage("success.required", mapping.getPath());
> >> log.error(message);
> >> throw new ServletException(message);
> >> }
> >> return forward;
> >> }
> >>
> >> 2. ParameterDispatchAction - A DispatchAction that selects a handler
> >> method
> >> using the value of the ActionMapping parameter.
> >>
> >> This is as per the suggestion by Anthony Kay via Bugzilla
> >> , except I
> >> prefer
> >> the name ParameterDispatchAction to his suggestion of
> >> ConfigDispatchAction
> >> as I think it's more descriptive of what the class actually does.
> >> Other than
> >> the name change, I've just tidied up the Javadoc and changed the
> >> 'unspecified' method to throw an Exception (as in DispatchAction) rather
> >> than return an Http error code.
> >>
> >> If no one has any problems with adding these two, I'll put them in
> >> tomorrow.
> >>
> >>
> >> Steve
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
--
Benjamin Tomasini <[EMAIL PROTECTED]>
NetEverything, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
On Fri, 2003-08-01 at 04:13, Vic Cekvenich wrote:
> I think less actions are needed, not more.
> .V
>
> Steve Raeburn wrote:
> > I'd like to add two new actions to org.apache.struts.actions that I find
> > particularly useful.
> >
> > 1. SuccessAction - A simple action that forwards control to an ActionFoward
> > named "success".
??? I had this action, but realized...
does the same thing. So I removed it.
Seems the addition of a SuccessAction would me redundant with current
Struts features.
> >
> > This is a very simple action, but I find it exceptionally useful,
> > particularly in the early stages of development when it can act as a
> > placeholder for as-yet undeveloped actions.
> >
> > public ActionForward execute(
> > ActionMapping mapping,
> > ActionForm form,
> > HttpServletRequest request,
> > HttpServletResponse response)
> > throws Exception {
> >
> > ActionForward forward = mapping.findForward("success");
> > if (forward == null) {
> > String message =
> > messages.getMessage("success.required", mapping.getPath());
> > log.error(message);
> > throw new ServletException(message);
> > }
> > return forward;
> > }
> >
> > 2. ParameterDispatchAction - A DispatchAction that selects a handler method
> > using the value of the ActionMapping parameter.
> >
> > This is as per the suggestion by Anthony Kay via Bugzilla
> > , except I prefer
> > the name ParameterDispatchAction to his suggestion of ConfigDispatchAction
> > as I think it's more descriptive of what the class actually does. Other than
> > the name change, I've just tidied up the Javadoc and changed the
> > 'unspecified' method to throw an Exception (as in DispatchAction) rather
> > than return an Http error code.
> >
> > If no one has any problems with adding these two, I'll put them in tomorrow.
> >
> >
> > Steve
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Benjamin Tomasini <[EMAIL PROTECTED]>
NetEverything, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
--- Steve Raeburn <[EMAIL PROTECTED]> wrote:
> I'd like to add two new actions to org.apache.struts.actions that I find
> particularly useful.
>
> 1. SuccessAction - A simple action that forwards control to an
> ActionFoward
> named "success".
>
> This is a very simple action, but I find it exceptionally useful,
> particularly in the early stages of development when it can act as a
> placeholder for as-yet undeveloped actions.
>
> public ActionForward execute(
> ActionMapping mapping,
> ActionForm form,
> HttpServletRequest request,
> HttpServletResponse response)
> throws Exception {
>
> ActionForward forward = mapping.findForward("success");
> if (forward == null) {
> String message =
> messages.getMessage("success.required", mapping.getPath());
> log.error(message);
> throw new ServletException(message);
> }
> return forward;
> }
I'm not a big fan of Struts hardcoding things like forward names or
message keys in the standard distro. We shouldn't be dictating that type
of thing. Why can't you use a ForwardAction to acheive this type of
functionality?
>
> 2. ParameterDispatchAction - A DispatchAction that selects a handler
> method
> using the value of the ActionMapping parameter.
>
> This is as per the suggestion by Anthony Kay via Bugzilla
> , except I
> prefer
> the name ParameterDispatchAction to his suggestion of
> ConfigDispatchAction
> as I think it's more descriptive of what the class actually does. Other
> than
> the name change, I've just tidied up the Javadoc and changed the
> 'unspecified' method to throw an Exception (as in DispatchAction) rather
> than return an Http error code.
I have no problems with this one. I don't currently use DispatchAction
but is there a way the proposed behavior could be included with that class
instead of a new one?
David
>
> If no one has any problems with adding these two, I'll put them in
> tomorrow.
>
>
> 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]
Re: Addition of two new actions
I use many utilities Actions like these, and the result is that fewer
*custom* Actions are needed. I think increasing the number of standard
Actions in the distribution is a very good idea. It makes Struts more
accessible to newcomers, saves everyone from reimplementing the same
design, and leverages the fact that Actions are singletons.
-Ted.
Vic Cekvenich wrote:
I think less actions are needed, not more.
.V
Steve Raeburn wrote:
I'd like to add two new actions to org.apache.struts.actions that I find
particularly useful.
1. SuccessAction - A simple action that forwards control to an
ActionFoward
named "success".
This is a very simple action, but I find it exceptionally useful,
particularly in the early stages of development when it can act as a
placeholder for as-yet undeveloped actions.
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
ActionForward forward = mapping.findForward("success");
if (forward == null) {
String message =
messages.getMessage("success.required", mapping.getPath());
log.error(message);
throw new ServletException(message);
}
return forward;
}
2. ParameterDispatchAction - A DispatchAction that selects a handler
method
using the value of the ActionMapping parameter.
This is as per the suggestion by Anthony Kay via Bugzilla
, except I
prefer
the name ParameterDispatchAction to his suggestion of
ConfigDispatchAction
as I think it's more descriptive of what the class actually does.
Other than
the name change, I've just tidied up the Javadoc and changed the
'unspecified' method to throw an Exception (as in DispatchAction) rather
than return an Http error code.
If no one has any problems with adding these two, I'll put them in
tomorrow.
Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ted Husted,
Junit in Action - ,
JSP Site Design - .
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
I think less actions are needed, not more.
.V
Steve Raeburn wrote:
I'd like to add two new actions to org.apache.struts.actions that I find
particularly useful.
1. SuccessAction - A simple action that forwards control to an ActionFoward
named "success".
This is a very simple action, but I find it exceptionally useful,
particularly in the early stages of development when it can act as a
placeholder for as-yet undeveloped actions.
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
ActionForward forward = mapping.findForward("success");
if (forward == null) {
String message =
messages.getMessage("success.required", mapping.getPath());
log.error(message);
throw new ServletException(message);
}
return forward;
}
2. ParameterDispatchAction - A DispatchAction that selects a handler method
using the value of the ActionMapping parameter.
This is as per the suggestion by Anthony Kay via Bugzilla
, except I prefer
the name ParameterDispatchAction to his suggestion of ConfigDispatchAction
as I think it's more descriptive of what the class actually does. Other than
the name change, I've just tidied up the Javadoc and changed the
'unspecified' method to throw an Exception (as in DispatchAction) rather
than return an Http error code.
If no one has any problems with adding these two, I'll put them in tomorrow.
Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Addition of two new actions
I'd like to add two new actions to org.apache.struts.actions that I find
particularly useful.
1. SuccessAction - A simple action that forwards control to an ActionFoward
named "success".
This is a very simple action, but I find it exceptionally useful,
particularly in the early stages of development when it can act as a
placeholder for as-yet undeveloped actions.
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
ActionForward forward = mapping.findForward("success");
if (forward == null) {
String message =
messages.getMessage("success.required", mapping.getPath());
log.error(message);
throw new ServletException(message);
}
return forward;
}
2. ParameterDispatchAction - A DispatchAction that selects a handler method
using the value of the ActionMapping parameter.
This is as per the suggestion by Anthony Kay via Bugzilla
, except I prefer
the name ParameterDispatchAction to his suggestion of ConfigDispatchAction
as I think it's more descriptive of what the class actually does. Other than
the name change, I've just tidied up the Javadoc and changed the
'unspecified' method to throw an Exception (as in DispatchAction) rather
than return an Http error code.
If no one has any problems with adding these two, I'll put them in tomorrow.
Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
