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
