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]
