Leo Simons wrote:
>>>It is a tradition, a recommendation, and a "best practice". It is _not_
>>>a requirment.
>>>
>>>
>>I have to question this "best practice".
>>
>>
>
>it is because your components will be useable in the broadest possible
>scope: ECM, phoenix, SM, merlin, ... very importantly: cocoon.
>
>And it doesn't really "hurt". Or does it? (...)
>
>
That's the key question.
Avalon Framework is the reference point - but the framework does not
define "how" a container should be implemented - which is a good thing.
This independence from container implementation has allowed the
emergence of different implementation approaches - ECM, SM, Phoenix,
Merlin, etc. In each case there is the introduction of additional
information constructs which help to simplify/control/automate the
process of component management (in the broad sense of the word).
However, these additions basically represent families in terms of
component portability. The only way to avoid this is to address
interoperability interfaces - basically isolating and resolving the
differences between approaches and from that, establishing a common
ground. For example, the ongoing metainfo/metadata activity is a result
of identification and isolation of a object model that will enable a
high level of interoperability between Phoenix and Merlin. At this time
both Phoenix and Merlin use the DefaultServiceManger and
DefaiultComponentManager implementations - however, that decision can be
abstracted out by using a provider. The combination of an open model
for the declaration of a component type together with pluggable
providers will lead to complete interoperability across components. But
this requires that we be very strict about separation and isolation of
assumptions and practices that effect the component contract. For
example, the notion of role == interface name + magic keywords makes
sense for a specific class of container. In such a scenario, the
component must be able to declare that it is dependent on type of CM/SM
- and this is meta info (information about the component type). A
kernel can recognize and apply these constraints providing we establish
a common component type model.
Without that in place, the addition of any semantics over and above the
framework notions will "hurt" if and when you switch a component from
one family to another.
Cheers, 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]>
