Peter Donald wrote:
> 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.
No I don't - all I'm asking for is the hook.
What I want is that you add the following operation to ComponentMetaData:
/**
* Returns the context object for the component.
* @param parent the parent context
* @return the context object to be supplied
*/
public Context getContext( Context parent )
{
return context;
}
>
>
> 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.
NO NO NO &%#####**!�$%^&
I would like to see different containers using containerkit. I would
prefer that the center of interoperability is based on containerkit.
I've provided several examples of why containerkit breaks this for
existing components and goes against the general component model as
documeted. I've provided info on how an implementation can address this
in response to your claims that it is impossible. I've put up with
being accused of of having an IQ in the single digit range, accused of
strange and amazing anti-component practices, I'm now accused of
attempting to force a solution! Please keep in mind that your objection
to the original proposal of a accessor to context was on the grounds
that (a) it was exclusively a container concern, following which you
raised the assertion was made that it was impossible anyway (leading to
a lot of explanitory emails explaining how it is possible).
I've proposed an operation to be added to ComponentMetaData above.
Are you going to commit it or am I?
Cheers, Steve.
>
>
> 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]>
>
--
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]>
