My design preference for things like this (as is playing out in
Struts 1.3) is to define a single scoped bean which can contain any
references like this, so as to sharply minimize the need for
constants like this. If you do that, then you're down to a single
constant to use to retrieve that bean, and then everything else can
be retrieved via strongly typed accessors, which plays nice with IDE
autocompletion and tools like that.
This Globals class defines request and session-scoped keys -- one
could debate whether Ti should have beans for each, or whether, like
Struts 1.3 (and the HTTP Servlet API), one can assume that a request
always has a reference to its corresponding session.
Assuming that you don't want to abstract away the essential
request/response nature of webapps, it's easy enough to make a
RequestContext (which would be much like the Struts 1.3
ActionContext) and give this class the responsibility for managing
attributes which are important to the framework but which also need
to be exposed in various runtime scopes.
Then, this constant would only need to be defined on a bridge class
that has the responsibility for guiding things from the controller
realm to the view realm. I'm not sure whether Ti has any such yet
(or what it would be if it doesn't) but the constant represents a
contract with the view layer (you'll find these resources *here*), so
it shouldn't be considered global. The framework itself shouldn't
need globals, for the same reasons we don't use maps when we can use
JavaBeans.
I think that lack of encapsulation (lots of direct access to request
and session via constants) in Struts is one of its weakest points,
making it hard to test and hard to refactor, so I'd hate to see Ti
make the same mistakes...
Joe
At 9:00 PM -0600 8/30/05, Rich Feit wrote:
It's transitional -- not necessarily for back-compat. I should have
commented it as such. In Beehive, we were using these four
constants that Struts defined for storing errors, exceptions,
locale, etc. I think it's something we need to work out -- do we
want to keep storing these things in attributes with well-known
names? If not, the Globals class can go away -- replaced by
internal constants and APIs. I'd be in favor of that, but I didn't
want to make a unilateral decision.
The use of these attributes isn't tied to the Servlet API, though --
we set them through the WebContext abstraction.
I'll put an @todo on this class in my next patch.
Rich
James Mitchell wrote:
So, while working on the shale build, I'm multitasking over to Ti
and looking through some of the code there.
The first thing that strikes me as odd is o.a.t.Globals.
I mean, I thought one of the goals was to completely abstract any
underlying api (servlet/portlet). Am I misunderstanding this? Or
is this for backward compatibility?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: [EMAIL PROTECTED]
Skype: callto://jmitchtx
---------------------------------------------------------------------
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]
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
