struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Struts Wiki] Update of "RoughSpots" by GabrielZimmerman
Date Wed, 26 Apr 2006 04:24:02 GMT
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message