This would explain why I wasn't able to reset the object at the top of the stack in an "after" call and see the results. +1 from me for this functionality. Though perhaps the "AroundInterceptor" should be modified or extended so that there's something as simple to use as it is now, with specific "before", "preResultBefore", "preResultAfter", and "after" methods. To be honest, maybe it makes sense to rename and reorganize those methods or do this in another class to make the naming a little more intuitive, like
class: LifecycleInterceptor methods: beforeExecution afterExecution afterResult The idea of registering listeners sounds flexible but something like the suggestion above seems like it would cover 90% of the uses. I'm guessing that any listener registration could go on behind the scenes in this new interceptor class, and you could still have other interceptors that don't inherit from this use the listeners to implement the same functionality themselves. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cameron Braid Sent: Thursday, November 13, 2003 4:16 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Problems with code after actionInvocation.invoke() +10 for me for implemeting PreResultListeners. It is something that I asked for a long while ago. I think that xwork interceptors are a little strange since they don't intercept JUST the execute method call. because the result is executed before the interceptor finishes. Cameron. Francisco Hernandez wrote: > 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 > -- 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/distributedComputing/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
