On 08.Oct.2002 -- 03:17 PM, Carsten Ziegeler wrote:
> Christian Haul wrote:
> >
> > On 08.Oct.2002 -- 02:17 PM, Carsten Ziegeler wrote:
> > > Sylvain Wallez wrote:
> > > >
> > > > Good, we're in accordance again ;-)
> > > >
> > > Yup.
> > >
> > > > However, can you explain the exact purpose of
> > > > <map:component-configurations>, and how it is handled ?
> > > >
> > > > I see that it is now defined in the Processor interface, but can't
> > > > understand how it is used and what CocoonComponentManager exactly does
> > > > with it (this stack management is black magic).
> > > >
> > > > How is it related to <map:components> which is nothing more than the
> > > > configuration of a ComponentManager and can thus hold any component
> > > > declaration ?
> > > >
> > > Ok...this whole thing is a cool (FS-like) implementation of dynamically
> > > configured components....still there?...
> >
> > Carsten, could you explain in a few words how this differs from the
> > modeConf parameter in the InputModule interface and what makes it
> > better here?
> >
> First, it's a general approach which works for all components (at least
> those
> looked up using the ComponentManager - it does not work for selectors).
> It is currently used and it works.
OK. But the "configuration at runtime" argument should hold here, too,
or be ignorable for the InputModules as well.
LifeCycle does not make sense for InputModules, so it would be the
only possibility to pass them on the go.
> And it allows to configure components in the sitemap which are *not*
> declared there - the cocoon user does not notice that these are
> Avalon components.
Dito.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
