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]>
