Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ 1. Allow indexable parameters similar to how it works in struts (with indexed="true") but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189]. This is unfortunately not trivial at all. 1. Get rid of the use of static constant variables that are used in the key in the stack and accessed all over the place like XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the OgnlContextState class, but it's not complete and I'm not sure if that's the best way to do it. 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. - * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. + * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. + * [Gabe] It is an advantage for Interceptors to be able to clean up at the end of a request, but it isn't great how they do that either. Take for example an action chain. If you have a create connection Interceptor surrounding each of the chained actions, you will open two connections, which besides being wasteful could cause problems with other resource types. I wonder if we can create some sort of request scoped ResourceManager class that can allow Interceptors to create resources or access them if they exist and specify how they should be destroyed at the end of the request. Thus in the connection case, the Interceptor could check if the resource manager had one and if not create it and add it to the resource manager for other objects to use. (Another option of course is an inversion of control approach) == Tim's Issues == I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
