Leo Sutic wrote:
>Stephen,
>
>the ability to pass in complex types is not enough of a difference
>to make Context different from Configuration for the portable component
>case.
>
Ouch!
That's a really nasty restriction. Given that it is possible to declare
context creation for complex objects (e.g. Nicolas example of an object
implementing the Coocoon Context interface) - and the advantages that
provides in simplication of the API for the client - i.e. Nocola just
get the Cocoon context and interacts with that in a type safe manner -
compare that with a Configuration where the resoponsibity is now on
Nicola to deal with strings from a configuration in order to build the
object he really wanted - that's a rather painful overhead to apply -
especially when its not necessary.
>
>For the non-portable case I can see use of a Context, though. But if the
>component is tied to a specific container, what's the use of putting
>context dependencies in the xinfo?
>
None.
If is a non-portable component then its out of scope of this discussion.
This only concerns component that are container independent.This is way
the original post stated that we need to make a decision - if context
constraints reamin in the ComponentMetaInfo class in containerkit - then
we need a corresponding Context accessor in ComponentMetaData. If not -
we have drop the context support from the ComponentMetaInfo and leave it
up to specilizations of ComponentMetaInfo and ComponentMetaData to
provide this additional support. Providing one without the other is
completely inconsitent.
Steve.
>
>/LS
>
>
>--
>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]>
