Berin Loritsch wrote: [snip] > > 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. > > A Configuration != Manager, so I don't see how the cascading properties > will solve any real needs.
The CascadingConfiguration is not a manager. It is simply a Configuration that is backed by a parent configuration (just like Context can be backed by a parent context, or ComponentManager can be backed by a parent manager). This solves some "real needs" - you can supply default information under a parent configuration, and s subset configuration as the base configuration. When an implementation get an attribute value, the implementation looks at the base configuration first - if no value can be resolved, the implementation invokes the same request on the parent. The parent may be a classic configuration or a cascading configuration - so basically the resolution of the attribute value continues to a point where either a value is resolved, or, not value is available. The second aspect of cascading configuration behaviour concerns aggregation of child elements - get the children of a configuration node returns the children of the base configuration and allows the corresponding parent configuration children. It basically allows separation of things like default values from concrete data sets - which means elimination of duplicate configuration data. Cheers, Steve. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
