On Tue, 12 Feb 2002, Berin Loritsch wrote: > Torsten Curdt wrote: > > Wouldn't it make sense to also have a > > > > class CascadingConfiguration extends AbstractConfiguration { > > > > public CascadingConfiguration( Configuration conf ) { > > ... > > > > So we can apply the same pattern as for the ComponentManager or the > > RoleManager? So you easily split configuration files... > ? How do you see this working?
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. > 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? > A Configuration != Manager, so I don't see how the cascading properties > will solve any real needs. Can you see now? Actually I just hit the same wall like Marcus Crafter did recently. Looking for a nice way for a user-xconf for Cocoon ;) > There is something else that I want to work towards (but am not anywhere > near ready yet), which is a ConfigurationManager--i.e. a repository for > Configuration objects for the different types of components. That way, > there can be two-way communication to allow a Component to rewrite its > configuration, and the ConfigurationManager will persist the change. Damn - that would be cool!! But as you pointed out... this will take some time ;) -- Torsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>