 |
History
| Log In
|
|
|
|
Patches for easy interceptor config overriding
New files:
test/com/opensymphony/xwork/config/providers/xwork-test-interceptor-params.xml src/java/com/opensymphony/xwork/config/entities/InterceptorMapping.java Matt,
the above patch allows "easy" overriding of interceptor stacks. Example of overridden Interceptor properties: <interceptors> <interceptor name="timer" class="com.opensymphony.xwork.interceptor.TimerInterceptor"/> <interceptor name="test" class="com.opensymphony.xwork.mock.MockInterceptor"> <param name="foo">fooDefault</param> </interceptor> <interceptor-stack name="defaultStack"> <interceptor-ref name="timer"/> <interceptor-ref name="test"/> </interceptor-stack> </interceptors> <default-interceptor-ref name="defaultStack" /> <action name="TestInterceptorParam" class="com.opensymphony.xwork.SimpleAction"> <interceptor-ref name="defaultStack"> <param name="test.expectedFoo">expectedFooValue</param> </interceptor-ref> </action> <action name="TestInterceptorParamOverride" class="com.opensymphony.xwork.SimpleAction"> <interceptor-ref name="defaultStack"> <param name="test.foo">foo123</param> <param name="test.expectedFoo">expectedFooValue2</param> </interceptor-ref> </action> I did not yet commit the code, cause I want some others to review it... Extremely cool patch. The problem I see is what if different interceptors have the same parameter names. Then if you override one, you override them all. Could we do instead something like: <action name="TestInterceptorParamOverride" class="com.opensymphony.xwork.SimpleAction"> <interceptor-ref name="defaultStack"> <interceptor-ref name="test"> <param name="test.foo">foo123</param> </interceptor-ref> </interceptor-ref> </action> Gabe,
this shouldn't be an issue... 'test' is the name of the referenced interceptor of the given stack. So only interceptors with the name 'test' will get this params applied. What do you think? Rainer,
really great patch. I agree with you that the parameter naming should not be an issue, since you did it hierarchical. It is really consistent with typical ognl features usage, so +1 from me for adding this to CVS. +1
I also think we should document this new cool feature and have one/few examples in our demo webapp. And should the .DTD file be documented to with this feature? Claus,
since there are no changes to be applied to the DTD, there shouldn't be a documentation need there. (Just to be curious, are there any explanation docs within the DTD?) But, you are right... We should and need to document this in the wiki. I will commit the code later today (had no stable DSL connection yesterday) , then we can update the docs accordingly... Matt,
patch is commited to CVS HEAD. You can try either from source or get the updated jars from the ivyrep at opensymphony. Thanks! I'll try to look at this (as well as the other fixed issues) in the next couple days. It's a hectic week for me.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Major
Allow easy overriding of "excludeMethods" and "includeMethods" of ValidationInterceptor
I added wildcard support for excludeMethods and includeMethods using the '*' character.
Please have a look if this works for you.
Furthermore I added result mapping with wildcard support.
If the resultCode is not found, additionally check for a '*' within the result mappings.
I will look into the "easy" overriding as soon.
cheers,
Rainer