On Sun, 24 Nov 2002 09:46, Darrell DeBoer wrote:
> Of course, there may well be a small set of contextual information which
> should be provided as part of the Context. Maybe a FileSystemContext makes
> sense as a generic extension to Context, which almost every container would
> provide. But the point is that such examples are few, and *all* can be
> treated as services, until such a time they become so universal that they
> require special treatment.
It is accepted that any bit of data in the context can either be though of as
a service or some configuration data and thus available either via
ServiceManager/ComponentManager or Configuration/Parameters.
The difference is essentially that Context provides "runtime" / "contextual"
or "environmental" data. ie It essentially provides the component with
data/services that only the parent container can provide.
You could mix concerns but that makes for a more complex configuration setup
as now you have to be aware of the differences between container provided and
peer provided services and how that effects interaction with them. It also
makes the internals of the container much harder to maintain. We actually
started to do that about 2 years ago but after a few months decided to back
it out.
The end result? You have replaced container specific context with container
specific services and container specific configuration/parameters blending.
And this all becomes more complex for end user and harder for us to maintain.
--
Cheers,
Peter Donald
-----------------------------------------------------
When a stupid man is doing something he's ashamed of,
he always declares that it is his duty.
George Bernard Shaw
-----------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
