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/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
