Don Brown wrote:
Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I actually agree that a single bean is better than a lot of separate
values under various keys. In Beehive we put most of our request-scoped
values onto a request wrapper -- this turned out to have better
performance than doing the attribute lookup all over the place. But
it's a similar idea.
JSF likes a single "context" bean as well (FacesContext). One choice
that JSF also made should be considered here, in terms of providing
access ... there's a static FacesContext.getCurrentInstance() method
that returns the current context object for the current request
thread (it's implemented with a ThreadLocal). The nice thing this
does is eliminates the need to have any magic attribute key at all,
as well as *having* to pass the context object in to every single
method call.
This is exactly what XWork provides, ActionContext, and it also uses a
ThreadLocal. I wrote a ControllerContext, which uses the map from
ActionContext as storage for its attributes, and Rich wrote a
PageFlowContext which extends ActionContext. Obviously, we need to
consolidate our contexts :) Still, I'm not convinced everything
can/should fall under one Context. For example, XWork has a
ValidationContext which I think we should keep separate but make
available through our primary context, whatever that may be.
Yes, in the end I hope there's a single point of access, but possibly
separate accessors for things like ValidationContext, ViewContext (?),
etc. I think it would be good for us to provide this as an implicit
object for the view tier, also.
Any thoughts about whether to extend ActionContext or have something
separate? I lean towards the former -- for simplicity and to avoid the
hashmap-lookup, which can have a real impact on performance
(String.equals()).
Rich
Don
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
