Berin Loritsch wrote:
> Sent: Tuesday, 12 February, 2002 15:22
> To: Avalon Developers List
> Subject: Re: Cascading Configuration
>
>
> Torsten Curdt wrote:
> > Every lookup of values will use the usual configuation object first.
> > If there is no such element the lookup is delegated to the parent
> > configuration.
>
>
> Keep in mind that each Container can add it's own include semantics.
> That is the general rule of thumb I am using for the AbstractContainer
> in the excalibur.system package. (Man it would be sweet if we can
> knock off the org.apache.avalon prefix--I say know after arguing against
> it in the past :/ )
>
> The include semantics would be something like this:
>
> <root include="foo.xconf">
> </root>
>
> In this case, the included elements would be included as a child of the
> element.
>
> <root>
> <xi:include href="foo.xconf"/>
> </root>
>
> In this case, the included elements would replace the
> <xi:include/> element.
>
> In the latter case, using the XInclude semantics from W3C, it can be built
> into the Parser object: with the <parameter
> name="support-xinclude" value="true"/>
> parameter.
>
> Would that satisfy the requirements?
That a static declaration.
CascadingConfiguration deals with dynamcially constructed configurations.
A manager can select a base configuration (e.g. based on some policy)
and suppliment this with a default configuration. You can't do that
with an include statement.
> >>Seriously, the Configuration works fairly elegantly right now. If I
> >>have a child that uses a Configuration block, I send the child to it.
> >>That Child Component cannot see any configurations from the parent.
> >
> > That's true is really nice right now. But it having the
> > CascadingConfiguration gives us the possibility to split
> > configurations over multiple file (without ugly XML entities ;)
> >
> > Should be an nice addition to Excalibur maybe?
Or DefaultConfiguration ? :-)
>
> :/
>
> I think what you really want is configuration including--not necessarily
> Cascading Configuration objects--although that approach would enable a
> template configuration tree that had defaults....
Exactly!
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
