Craig McClanahan wrote:
On 8/31/05, Rich Feit <[EMAIL PROTECTED]> wrote:
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?
There hasn't been trouble that I'm aware of, but think about the alternative
for a second. How much protection do your internal objects and properties
have when you use a magic attribute key in some scope? :-)
In practical terms, I think it's fair for the context object to have a
property that returns some opaque (to the application) object that is
reserved for use by the framework.
Craig
I'm with you on that one -- I think magic attribute keys are the the
least attractive option. There is something legitimizing about having a
property exposed on a public context, though. I guess I'd lean towards
the option you're suggesting (opaque object exposed for framework code).
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
