At 07:02 PM 7/3/2002 +0200, you wrote:
>So if we use two constraints:
>
> + What interfaces the Context must implement (that is, to what
> other type can you cast the aquired Context interface).
>
> + What values must it have (that is, what are the keys to the
> get() method), and what should the type of those values be.
>
>That's it as far as constraints are concerned. This we can standardize.
No problem there. After all I did write the ContextDescriptor to do just that.
>Now for Stephen's method of populating the Context via application
>profile, we can make that container specific.
I have no problem with that - it can't hurt me if it is container specific.
Stephen however wants to force everyone else to adopt his model.
In summary: I don't think there's a problem with the constraint spec,
>as it allows one to describe all the possible uses of a Context that
>I have seen so far.
right. I think the ContextDescriptor is great - I wrote it so obviously I
aint going to object to it.
For the container-specific parts (the container-specific configuration
>for the component), that will not affect any current usage of the
>Context, and need not be implemented.
The problem is Stephen wants add it to ComponentMetaData and thus force all
containers to use a single method for constructing context - despite the
fact that this wont work in any existing container except Merlin .... hmmm.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
