Sylvain Wallez wrote: > > Leo Sutic a écrit : > > > > So if I could vote, it would be a +1. > > And I also agree :) Just to make it really clear : I'm not at all > against namespaces in Configurations. It is required in some cases, and > Berin is facing such a case. I was just wondering if the increased > fonctionnality will not make Configuration look like a new DOM > alternative.
I doubt it. Hopefully it is not the case. For one thing there is no way to traverse UP the hierarchy. This is by design, and I would be adamantly opposed to anything suggesting such a change. I do not want developers to think of Configuration as an alternative to DOM, but I do want to provide additional information that is expressed in the XML that cannot currently be transferred to configuration space. Hopefully noone will think that Configuration is a reasonable alternative to DOM. > > (In fact, I'd like to extend the Configurable interface with one method: > > > > Node getValueAsDOM (); > > > > Then, you can not only store Strings, ints, booleans and floats, but also > > XML data in configurations.) > > > > /LS > > ??? Are you talking about a Configuration->DOM converter ? That's what I > was suggesting... That may be possible, but I not sure that is what we want. We do have a ConfigurationSerializer class that can serialize the configuration information to an output stream. It technically could be adapted to generate a DOM tree, but I am skeptical about the usefulness of such a transformation. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
