Which implies the following:
|-----------------------------------|
| container |
| |
| | creates |-----------|
| creates and prepares components | -------------> | component |
| using CM/SM which are private to | | |
| the container and the component | | |
| implementation | | |
| | | |
|-----------------------------------| | |
^ | |
| uses container to | |
| create new components | |
v | |
|------------------------------------| |-----| | |
| ComponentRegistry |---->| CM |<--| |
| Serves component requests | |-----| | |
| | | |
| | query | |
| | <------------ | |
| | | |
| | service | |
| | -----------> | |
|------------------------------------| |-----------|
Stephen McConnell wrote:
>
>
> Vadim Gritsenko wrote:
>
>>> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>>
>>
>>
>> <snip/>
>>
>>
>>
>>> In the context of Cocoon (which I don't know much about), it
>>> appears that ECM is being used as an object repository. A
>>> sitemap processor is basically invoking lookup on ECM to get
>>> the pre-configured components that it wants. From all of the
>>> discussion so far, it seems to me that ECM is serving these
>>> request out of the lookup operation - and I think this is
>>> breaking the thinking pattern - and potential solutions.
>>>
>>> Let me explain:
>>>
>>> Imagine we design a modern, clean container. Imagine that
>>> the lookup operations is *never* exposed to anything but a
>>> component instance that has been instantiated by the container,
>>> and to which the container has supplied a component manager.
>>> In this situation, the component manager knows the classname
>>> of the component, know lookup labels based on the components
>>> meta-info, knows the service to include in the supplied manager,
>>> can basically take care of everything to completely satisfy the
>>> component. HOWEVER, how does the container serve request for
>>> components to a client?
>>>
>>
>>
>> Stephen,
>>
>> Let me correct you a bit before somebody else does :)
>>
>
> Given my knowledge of Cocoon and ECM - yep - I'm open to
> corrections:
>
> :-)
>
>>
>>
>> Cocoon's sitemap processor *is* a component, managed by the container,
>> and instantiated by container, and provided with component manager by
>> container.
>>
>>
>
> Mechanically - yes - but the very fact that ECM does not deal with
> dependencies means that component is responsible for component selection
> via a query (as distinct from Merlin/Phoenix where the container does the
> selection and handes the compoent only what it needs).
>
> Problem is that the semantic that are assumed in ECM are that the
> component
> under composition is free to ask for any service - which means that the
> model of interaction is that the component being serviced is acting as a
> client towards a component registry. In this model, restrictions to
> scalability are infurred by the expresssiness of the repository lookup
> interface (in ECM the ComponentManager interface is being used as the
> repository query interface). This is the important distinction.
>
> Workarounds to this include the ComponentSelector - enabling the
> client to
> enter into a finer-grain of selection semantics. As the application
> complexity grows, debate on additional parameters on the lookup operation
> emerge as solutions to the problem. In fact, the problem is that the
> manager is being used as a repository. If we can figure a way of
> breaking
> out of this usage pattern then life will become a lot easier.
>
> I sure the following will raise a torrent of objections, but its an
> example of seperating concerns:
>
> 1. Component manager check component type it is instantiating
> for its formal, contractual dependecies - if available, the
> the manager provides only these service in the service
> manager.
>
> 2. If the component implements composable/serviceable and no
> dependecies are declared - we can assume (a) its a broken
> component, or (b) its a component that is implicity
> requesting a component repository service.
>
> I.e. component composable imp:
>
> public void lookup( String role )
> {
> ComponentRepository rep = (ComponentRepository)lookup(
> ComponentRepository.ROLE );
>
> final String role = Something.ROLE; Query
> query = getQuery();
> Object object = rep.query( role, query );
> }
>
> 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]>
