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
