Torsten Curdt wrote:
>>>>>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...
No, it is the responsibility of the Container to require or allow those semantics.
The reason being is that not all container allow or should allow configuration
including.
> At least that would be nicer than the XML entity approach.
True.
>
>
>>>>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
I think the AbstractConfiguration with the parent constructor would be enough.
I think we may be doing it with Parameters as well.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
