> >>>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. > > > 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.
This is already working? Ups, didn't now that... > 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? At least that would be nicer than the XML entity approach. > >>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? > > > :/ > > 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... Yes, including was it in the first place... but I now I really like this approach... I'm sure one can say it comes from the FS at the moment ;) but I'm sure there some nice use-cases for this... But what I like most about it... it's so straight forward when programming... The CM does it, the RM does it, so I thought this might also be possible with the Configuration (altough it's not a Manager) but I don't think this pattern has to be tied only to Managers. Maybe it makes even more to just add another constructor to the AbstractConfiguration class and implement in there. "Cascading" _might_ not exactly the right name... don't know -- Torsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
