Global results are only global for the package where they are defined. They are also inherited, as are default interceptors, etc.
There is no configuration outside the scope of a package. > -----Original Message----- > From: Robert Nicholson [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 30, 2003 9:59 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Referencing default stack from a package? > > > Well I guess I'll accept the way things are as I wasn't contributing > when you guys were hammering this stuff out way back when. > > I just thought that it was easier to think of it simply as anything > global > would be defined at the default package level and simply > inherited thru > all child > packages and their actions. > > So I would have expected there to be a root package level whereby you > could define "global" things implicitly without the need for a global > prefix and sub packages would simply inherit those definitions. > global-results looks like it comes from struts but struts doesn't > support packages or inheritance to my knowledge. This is how I would > have > expected interceptors to work also. Define a stack inherit it's > definition otherwise override it's defintiion. > > On Nov 30, 2003, at 8:32 PM, Jason Carreira wrote: > > > You can define global results for all of your actions inside a > > <global-results> block like this: > > > > <global-results> > > <result name="login"> <!-- should be chain type > since it > > is the default --> > > <param name="actionName">login</param> > > </result> > > </global-results> > > > >> -----Original Message----- > >> From: Robert Nicholson [mailto:[EMAIL PROTECTED] > >> Sent: Sunday, November 30, 2003 9:15 PM > >> To: [EMAIL PROTECTED] > >> Subject: Re: [OS-webwork] Referencing default stack from a package? > >> > >> > >> Is it possible to define a default error result > (dispatcher) simply > >> by defining a result at the package level instead of the action > >> level? I don't have to say default-result for that right? > >> > >> Consistency is better than simplicity. > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.net email is sponsored by: SF.net Giveback Program. Does > >> SourceForge.net help you be more productive? Does it help > you create > >> better code? SHARE THE LOVE, and help us help YOU! Click Here: > >> http://sourceforge.net/donate/ > >> _______________________________________________ > >> Opensymphony-webwork mailing list > >> [EMAIL PROTECTED] > >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >> > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: SF.net Giveback Program. Does > > SourceForge.net help you be more productive? Does it help > you create > > better code? SHARE THE LOVE, and help us help YOU! Click Here: > > http://sourceforge.net/donate/ > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us > help YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
