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.
For publicly-exposed attributes, I do like the idea of providing a
single public bean, available through an API, and also exposed as an
implicit object for binding in the view tier:
${ti.someProperty}
or, in a JSF page:
#{ti.someProperty}
The only question I can think of here is whether this bean is anything
separate than our ActionContext.
Note that currently in the Page Flow code, there is a mishmash of the
use of *internal* constants/values. Most things are found on our
ActionContext (PageFlowActionContext), which contains an inner bean
(State) which it puts on the request when it wants certain values to get
passed through to the view tier (which also has access to a
PageFlowActionContext). This is a carryover from the request wrapper in
Beehive. I'm hoping that in the end, you could ask our ActionContext
for whatever you need, but I think this general issue is something that
needs to get hashed out.
Thoughts?
Rich
Joe Germuska wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
