Niclas Hedhman wrote, On 14/07/2003 9.42:
Stephen wrote:
I hate this subject because I keep changing my mind!
Isn't that a good thing?
:-))
<snip reason="agree" />
I still don't get the example you write, Stephen: "Context represents an import stage during which a container can gather non-component artifacts and apply them to a component before servicing occurs. A context entry could be something like a KeyStore which can be used by a component during the servicing stage (as an example)".
Could you please explain a bit more in detail?
TIA
...
From my perspective (being, or trying to be, mainly a component author) it is fairly irrelevant whether it is in the Contextualizable or Serviceable contract, as long as;
1. It is a single lookup. 2. If the container doesn't provide it by default, I can provide an implementation.
And your suggestions above seems to fulfill this very well, the rest is implementation details ;o).
I tend to agree.
Do the ones that *use* containers need to implement the Context and cannot use a Service instead? Because this is the main point IMHO.
If users need only to make Services and make the container handle them, there is no need to give them this ability of adding things to a Context, as they can be done as a Service.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
