Re: Context: usage recommendations?

[Stephen McConnell]

Adam Murdoch wrote:

Hi,

It would be really useful to take a step back, and first figure out *what* a Context is, and *what* a ServiceManager. Let's leave figuring out *how* to populate them until we know what they are. We don't even know whether they're distinct things yet.

If you take out the container constraint of "what is a context supplied object" you left with lifecycle aspects as the only distinguishing feature.

For example, the only real answer to the 'what is the difference between a context and a service manager?' question I've had so far is 'they're different because people think of them as different things'. Which is fine, except no-one seems to be able to explain what the difference is, and why that difference is important enough to model in framework.

This is the crux of the matter. Not whether it's *possible* to make the distinction, but whether it is *useful* to make the distinction. Maybe it is, maybe it isn't. (Hint: the distinction must be meaningful across *all* containers. It can't be "well, it means this sometimes, and it means that at other times").

I also wonder how much of "people think of them as different things" is due to the fact that framework has a thing called "Context" and another thing called "ServiceManager", and "well .. um .. of course they're different things, otherwise they wouldn't be there". In other words, are we trying to invent a meaning for Context because Context currently happens to be part of framework?

I can't argue against this!

On Sun, 8 Dec 2002 05:42 am, Stephen McConnell wrote:

A second interesting point is that the component author has 100% control
over which services and locators are mapped to the context abstraction
as opposed to the service abstraction.

and later:

From here, the differentiating factor between contextualization and
services phases is reduced to the ordered sequence in the lifecycle.

But service() is called immediately after contextualize(). How is it useful for the component writer to be able to map resources between these methods when they're called one-after-the-other? Why bother?

Because I feel real comfortable with the destinction - and the distinction I'm applying is data centric versus service centric - and yes their both objects - but that's not important - what's important is that it feels right.

:-)

Surely it would be easier for everyone involved to simply collapse those 2 methods?

Aside from feeling good, this gets into the "Recontextualizable" area. In just about all of the components I work with, the context values tend to be the state that the components uses relative to a set of underlying services, combined with its own logic.

I have several specific instances of components that could benefit greatly by container supplied recontextualization. The service mapping remains the same - only the data supplied to the component changes.

Consider the following sequence:

-> contextualize
-> service
-> initialize
-> start

... stuff happens

-> suspend
-> recontextualize
-> resume

... stuff happens

-> stop
-> dispose

Cheers, Steve.


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>