This was the original design, but we were unable to adequately control whether the results were executed or not (sometimes you don't want them to be).
I'll take a look again and see if this would be possible (since it really would simplify things a bit)... Jason > -----Original Message----- > From: Tim Dwelle [mailto:[EMAIL PROTECTED] > Sent: Friday, November 14, 2003 10:40 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Problems with code after > actionInvocation.invoke() > > > I know its a bit more radical... but it seems to me that a > better solution would be to move the code for dispatching to > the appropriate result into its own interceptor. > > Then you don't need these lifecycle methods. And more > importantly, it eliminates this uncomfortable mix of "some > workflow is handled by interceptors, while others are not". > > Just a suggestion... > > -Tim. > > > > > ----- Original Message ----- > From: "Jason Carreira" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, November 14, 2003 10:07 AM > Subject: RE: [OS-webwork] Problems with code after > actionInvocation.invoke() > > > > Gavin King has convinced me to take another look at this... Tonight > > I'll look at creating another base class which has: > > > > before() > > beforeResult() > > after() > > handleException() > > > > And will have a try/catch to allow you to be informed of > Exceptions in > > handleException(). > > > > AroundInterceptor will remain the simple class that it is... > > > > > > > -----Original Message----- > > > From: Jason Carreira > > > Sent: Friday, November 14, 2003 9:33 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [OS-webwork] Problems with code after > > > actionInvocation.invoke() > > > > > > > > > I don't want to add it to the base class, since none of > our current > > > bundled Interceptors need this. It should be easy enough > for people > > > who need it to have their own base Interceptor class to do this > > > (heck, I wrote it for you in a previous message)... > > > > > > > > > > > > > -----Original Message----- > > > > From: Cameron Braid [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, November 14, 2003 7:27 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [OS-webwork] Problems with code after > > > > actionInvocation.invoke() > > > > > > > > > > > > I think that this is a better idea. > > > > > > > > AroundInterceptor could have an empty implementation for this > > > > method... simple :) > > > > > > > > Cameron > > > > > > > > Francisco Hernandez wrote: > > > > > > > > > what if instead of having another Interceptor class we can > > > > just add a > > > > > new method to the Interceptor interface like beforeResult() ? > > > > > > > > > > Jason Carreira wrote: > > > > > > > > > >> I've just checked in the code for PreResultListener to > > > > XW/WW2... No > > > > >> changes to Interceptor base classes, etc... You guys try > > > > this out and > > > > >> see how you like it and how you're using it. > > > > PreResultListener is an > > > > >> Interface, with one method: > > > > >> > > > > >> void beforeResult(ActionInvocation invocation, String > > > resultCode); > > > > >> > > > > >> So don't limit yourself to just registering > Interceptors which > > > > >> implement this Interface.... That was just off the top > > > of my head. > > > > >> For now, I don't want to change the AroundInterceptor, > > > > since if they > > > > >> don't need it it's just extra overhead to register the > > > > listeners and > > > > >> call back to them for nothing... After some people start > > > > using them > > > > >> and we see how they're useful we can standardize > usage in base > > > > >> classes. > > > > >> > > > > >> Jason > > > > >> > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Drew McAuliffe [mailto:[EMAIL PROTECTED] Sent: > > > Thursday, > > > > >>> November 13, 2003 11:48 PM > > > > >>> To: [EMAIL PROTECTED] > > > > >>> Subject: RE: [OS-webwork] Problems with code after > > > > >>> actionInvocation.invoke() > > > > >>> > > > > >>> > > > > >>> Scratch my last comment; your example is exactly what I > > > > had in mind > > > > >>> as a new superclass to use for this kind of > > > > functionality. I think > > > > >>> such a superclass would be a great addition to the > > > > framework, though > > > > >>> it would have to be documented very well so that the > > > > >>> difference between before, beforeResult, and after is > > > > >>> explicitly > > > > clear This is > > > > >>> especially important considering the fact that the > > > > >>> JSP/velocity pages are already loaded before after() gets > > > > >>> called; > > > that wasn't > > > > >>> immediately apparent to me, and I'd imagine I'm not alone. > > > > >>> > > > > >>> -----Original Message----- > > > > >>> From: [EMAIL PROTECTED] > > > > >>> [mailto:[EMAIL PROTECTED] > > > > On Behalf > > > > >>> Of Jason Carreira > > > > >>> Sent: Thursday, November 13, 2003 5:55 PM > > > > >>> To: [EMAIL PROTECTED] > > > > >>> Subject: RE: [OS-webwork] Problems with code after > > > > >>> actionInvocation.invoke() > > > > >>> > > > > >>> No, it would be like this: > > > > >>> > > > > >>> > > > > >>> Public class MyInterceptor implements Interceptor, > > > > PreResultListener > > > > >>> { > > > > >>> > > > > >>> Public String intercept(ActionInvocation invocation) { > > > > >>> invocation.addPreResultListener(this); > > > > >>> String result; > > > > >>> before(); > > > > >>> result = invocation.invoke(); > > > > >>> after(); > > > > >>> > > > > >>> return result; > > > > >>> } > > > > >>> > > > > >>> Public void beforeResult(ActionInvocation > invocation) { // do > > > > >>> something before the result executes } > > > > >>> > > > > >>> } > > > > >>> > > > > >>> > > > > >>> So it would be like this: > > > > >>> > > > > >>> Interceptor1.before() > > > > >>> Interceptor2.before() > > > > >>> Action.execute() > > > > >>> Interceptor1.beforeResult() > > > > >>> Interceptor2.beforeResult() > > > > >>> Result.execute() > > > > >>> Interceptor2.after() > > > > >>> Interceptor2.after() > > > > >>> > > > > >>> Assuming both of these interceptors implemented > > > PreResultListener > > > > >>> and registered themselves with the ActionInvocation. > > > > >>> > > > > >>> Jason > > > > >>> > > > > >>> > > > > >>> > > > > >>>> -----Original Message----- > > > > >>>> From: Francisco Hernandez [mailto:[EMAIL PROTECTED] > > > > >>>> Sent: Thursday, November 13, 2003 6:40 PM > > > > >>>> To: [EMAIL PROTECTED] > > > > >>>> Subject: Re: [OS-webwork] Problems with code after > > > > >>>> actionInvocation.invoke() > > > > >>>> > > > > >>>> > > > > >>>> so let me get this straight with PreResultListener would > > > > be able to > > > > >>>> have interceptors work before/after execute before the > > > > Result gets > > > > >>>> called? > > > > >>>> > > > > >>>> that way we can have a flow like this using regular > > > interceptors > > > > >>>> and also PreResultInterceptors: > > > > >>>> > > > > >>>> before0 > > > > >>>> PreResultbefore1 > > > > >>>> PreResultbefore2 > > > > >>>> execute > > > > >>>> PreResultafter2 > > > > >>>> PreResultafter1 > > > > >>>> executeResult > > > > >>>> after0 > > > > >>>> > > > > >>>> am i understanding this correctly? > > > > >>>> > > > > >>>> Jason Carreira wrote: > > > > >>>> > > > > >>>> > > > > >>>>> Yes, this is the intended behavior. > > > > >>>>> > > > > >>>>> The issue is that Interceptors are stateless, so > you can't > > > > >>>>> do: > > > > >>>>> > > > > >>>>> Intercept() -> before -> execute -> after > > > > >>>>> Dispose() > > > > >>>>> > > > > >>>>> Because your Interceptor can't keep request specific > > > > state to be > > > > >>>>> disposed in another call... > > > > >>>>> > > > > >>>>> I'm wondering if it would be a good idea to have an > > > > >>>> > > > > >>>> > > > > >>>> Observer pattern > > > > >>>> > > > > >>>>> in here... PreResultListener.beforeResult(ActionInvocation > > > > >>>>> invocation)... Then Interceptors that want to be notified > > > > >>>> > > > > >>>> > > > > >>>> before the > > > > >>>> > > > > >>>>> Result could register with the ActionInvocation to have a > > > > >>>> > > > > >>>> > > > > >>>> callback... > > > > >>>> > > > > >>>>> This shouldn't affect any of the current code, and would > > > > >>>> > > > > >>> > > > > >>> just allow > > > > >>> > > > > >>>>> for one more lifecycle point.. Thoughts? > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: Daniel Pfeifer > > > > >>>>>> [mailto:[EMAIL PROTECTED] > > > > >>>>>> Sent: Thursday, November 13, 2003 11:06 AM > > > > >>>>>> To: '[EMAIL PROTECTED]' > > > > >>>>>> Subject: [OS-webwork] Problems with code after > > > > >>>>>> actionInvocation.invoke() > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> I am currently having trouble with a custom interceptor. > > > > >>>>>> The Interceptor is supposed to determine which values to > > > > set on the > > > > >>>>>> ValueStack by the resultstring it receives from > > > > >>>>>> actionInvocation.invoke(). The problem is: Once > > > > >>>>>> actionInvocation.invoke() is executed the whole flow > > > > is executed, > > > > >>>>>> even the ServletDispatcherResult is executed and thus the > > > > >>>>> > > > > >>> > > > > >>> JSP page > > > > >>> > > > > >>>>>> is already loaded before my interceptor had a chance to > > > > >>>>> > > > > >>> > > > > >>> modify some > > > > >>> > > > > >>>>>> invocation result based values. > > > > >>>>>> > > > > >>>>>> Is this the standard behaviour of Webwork 2.0 (latest CVS > > > > >>>>>> checkout) or should I file a bugreport in JIRA? If > > > this is the > > > > >>>>>> standard behaviour the reason for an after() in > > > > >>>>> > > > > >>> > > > > >>> AroundInterceptor is > > > > >>> > > > > >>>>>> beyond my comprehension (other than possibly doing some > > > > >>>>> > > > > >>> > > > > >>> clean-up and > > > > >>> > > > > >>>>>> in that case it should be called something like > dispose()). > > > > >>>>>> > > > > >>>>>> Thanks in advance, > > > > >>>>>> /Daniel > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> ------------------------------------------------------- > > > > >>>>>> This SF.Net email sponsored by: ApacheCon 2003, 16-19 > > > > >>>>>> November in Las Vegas. Learn firsthand the latest > > > > >>>>> > > > > >>> > > > > >>> developments > > > > >>> > > > > >>>>>> in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, > and more! > > > > >>>>>> http://www.apachecon.com/ > > > > >>>>>> _______________________________________________ > > > > >>>>>> Opensymphony-webwork mailing list > > > > >>>>>> [EMAIL PROTECTED] > > > > >>>>>> > > > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > >>>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>>> ------------------------------------------------------- > > > > >>>>> This SF.Net email sponsored by: ApacheCon 2003, 16-19 > > > > >>>>> November in Las Vegas. Learn firsthand the latest > > > > >>>> > > > > >>>> > > > > >>>> developments > > > > >>>> > > > > >>>>> in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! > > > > >>>>> http://www.apachecon.com/ > > > > >>>>> _______________________________________________ > > > > >>>>> Opensymphony-webwork mailing list > > > > >>>>> [EMAIL PROTECTED] > > > > >>>>> > > > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > >>>>> > > > > >>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> ------------------------------------------------------- > > > > >>>> This SF.Net email sponsored by: ApacheCon 2003, 16-19 > > > > >>>> November in Las Vegas. Learn firsthand the latest > > > > >>>> developments in Apache, PHP, Perl, XML, Java, MySQL, > > > WebDAV, and > > > > >>>> more! http://www.apachecon.com/ > > > > >>>> _______________________________________________ > > > > >>>> Opensymphony-webwork mailing list > > > > >>>> [EMAIL PROTECTED] > > > > >>>> > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> ------------------------------------------------------- > > > > >>> This SF.Net email sponsored by: ApacheCon 2003, > > > > >>> 16-19 November in Las Vegas. Learn firsthand the latest > > > > developments > > > > >>> in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! > > > > >>> http://www.apachecon.com/ > > > > >>> _______________________________________________ > > > > >>> Opensymphony-webwork mailing list > > > > >>> [EMAIL PROTECTED] > > > > >>> > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > >>> > > > > >> > > > > >> > > > > >> > > > > >> ------------------------------------------------------- > > > > >> This SF.Net email sponsored by: ApacheCon 2003, > > > > >> 16-19 November in Las Vegas. Learn firsthand the latest > > > > developments > > > > >> in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! > > > > >> http://www.apachecon.com/ > > > > >> _______________________________________________ > > > > >> Opensymphony-webwork mailing list > > > > >> [EMAIL PROTECTED] > > > > >> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwo > > > > >> rk > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email sponsored by: ApacheCon 2003, > > > > > 16-19 November in Las Vegas. Learn firsthand the latest > > > > developments > > > > > in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! > > > > > http://www.apachecon.com/ > > > > > _______________________________________________ > > > > > Opensymphony-webwork mailing list > > > > > [EMAIL PROTECTED] > > > > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwor > > > > > k > > > > > > > > > > > > > > > > > -- > > > > Any damn fool can write code that a computer can > understand... The > > > > trick is to write code that humans can understand. > [Martin Fowler > > > > http://www.martinfowler.com/distributedComputi> > ng/refactoring.pdf] > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email sponsored by: ApacheCon 2003, > > > > 16-19 November in Las Vegas. Learn firsthand the latest > > > > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and > > > > more! http://www.apachecon.com/ > > > > _______________________________________________ > > > > Opensymphony-webwork mailing list > > > > [EMAIL PROTECTED] > > > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webw ork > > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: ApacheCon 2003, > > 16-19 November in Las Vegas. Learn firsthand the latest developments > > in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! > > http://www.apachecon.com/ > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest developments > in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! > http://www.apachecon.com/ > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
