> -----Original Message-----
> From: Leo Simons [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 28 February, 2002 07:38
> To: Avalon Developers List
> Subject: RE: CascadingConfiguration --> framework ?
>
>
> > The class is basically an implementation of Configuration that
> > takes a primary and default configuration as constructor arguments.
> > Resolution of attribute values and child elements are resolved
> > against the primary configuration - and if that fails, the
> > implementation attempt to resolve the request against the
> > secondary default configuration (which could be another
> > CascadingConfiguration). Resolution of children for a particular
> > "name" result in the aggregation of the primary and default
> > configuration child elements.
> >
> > Thoughts ?
>
> Why not make CascadingConfiguration the "primary" as well?
The constructor just takes a Configuration as an arguement for
the primary and fallback configuration. So in-effect, you can
supply a cascading or classic configuration for either. The
implementation does not make a destinctioin between cascading
and classic configurations because the behaviour is exactly that
of a class Configuration instance.
Cheers, Steve.
> ie
>
> CascadingConfiguration
> {
> CascadingConfiguration( Configuration parent ) {}
>
> String getAtrribute( String attributeName )
> {
> if( hasAttribute(attributeName) )
> // return local;
> else
> {
> if( parent != null )
> return parent.getAttribute ( String
> attributeName );
> else
> return null;
> }
> }
> }
>
> or something along those lines. This way, you can even just add
> the extra constructor to DefaultConfiguration and modify its
> behaviour so that it cascades if a parent is provided. Seems
> more intuitive to me.
>
> grz,
>
> - LSD
>
> --
> To unsubscribe, e-mail:
<mailto:[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]>
