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 Bob Lee
Date Mon, 24 Apr 2006 22:36:38 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 Bob Lee:
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.
  
  == 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