Stephen,
1) What will the CM interface look like? I think you just end
up back where you started...
2) what is the difference between ComponentRegistry and a
ComponentSelector?
3) Could you go through Berin's use cases and show how this
looks like from a component's point of view?
It's nice and all, but:
+ We *still* have that CM interface there... Since that is
all that the component will see, the ComponentRegistry/container
part is hidden.
/LS
> -----Original Message-----
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> Sent: den 18 juni 2002 10:51
> To: Avalon Developers List
> Subject: Re: [A5] CM Use Cases from real requirements
>
>
>
> 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:avalon-dev-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
