Darrell DeBoer wrote:
On Sun, 24 Nov 2002 00:35, Stephen McConnell wrote:
In every single one of the examples you have provided above, the
extension of context is related to the exposure of a service. Take the
"forwardMail" example and image we want to create a component that is
complete and container agnostic. What we would do is declare that the
component in question has a dependency on a MailForwardingService. The
contract says nothing about where the service comes from (could be the
result of assembly, could be the result of a facility supplied by a
custom container). The point is that using *existing* Avalon Framework
contracts - this sort of dependency can be expressed providing we have a
consistent component model. Combine this with standard context entries
(avalon:home, avalon:work, etc) and the whole requirement for context
specialization disappears - or is at least pushed out into relatively
closed environments where component reuse outside of a particular
technical domain is of no interest.
This makes heaps of sense to me. The idea of a "MailForwardingContext" is a
perfect example of something that doesn't really fit the concept of a
*context*. It's really a *service* that provides the ability to forward mail.
A "ShutdownRequestContext" could, likewise, be seen as a *service* which
provides the ability to shutdown the container. The container may or may not
provide that service to certain components.
Following that, even the "DirectoryContext" (used for getBaseDirectory() etc)
could be seen as a "FileSystemService". (I'm just suggesting this as a
*possibility*, not necessarily *recommending* it). Imagine the possibilities
of using a Virtual File System (see commons-sandbox-vfs), so that the
component could be transparently be switched from Local file system, to
WebDAV, to zipfile, to whatever.
The way I see it:
1) We need a way for a component to declare it's dependencies on services.
2) Why should we invent another mechanism for container-specific contexts,
where 1) would suffice.
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.
+1
Good summary.
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]>
