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.
Craig
Using JSF is actually what convinced me that having the context on
ThreadLocal is a great thing. It really cleans up the APIs. (Nice job
BTW :) ). Our ActionContext will give us something similar... but I do
wonder about "internal" attributes -- those that our code uses but which
shouldn't necessarily be exposed publicly. I'm torn between:
- just putting them on the ActionContext
- creating a single gateway property on ActionContext for the
internal attributes
- using a subclass of our ActionContext, and casting down in our own
internal-attribute-aware code.
It looks like JSF went with the first option. Has this been any trouble?
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
