This makes more sense to me. You would expect an interceptor to wrap a single method call. However, you still need the ability to wrap an interceptor around the entire double whammy action-result invocation. There are really 3 separate invocations going on here - one which wraps the other two (action and result invocations).
If an "action interceptor" returned a null value then the result would not be executed. If WW2 gave the ability to intercept any of these then you could choose whether you wanted the result invocation bundled up. Almost like real AOP! All this is related to the fact that the String return value from the ActionInvocation.invoke() method is currently never used. ----- Original Message ----- From: "Tim Dwelle" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 14, 2003 3:39 PM 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-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 > > > > > > > > > > > > > > > > > -- > > > > 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-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-webwork
