> -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > Sent: den 1 oktober 2001 18:34 > To: Avalon Development > Subject: Re: [Vote] Namespace support for Configuration objects > > > Leo Sutic wrote: > > > > > I would be -1 on this. Configuration is built from SAX > > > currently, and adding > > > DOM nodes to the Configuration tree removes one of their main > virtues: the > > > fact that they consume fewer resources. > > > > That would only be a virtue if you have massive amounts of configuration > > data in the system. So much, in fact, that it overwhelms any > other category > > of objects. I have not encountered any example of this. > > I still don't see the value. In a configuration tree, you have > child configuration > objects. You have _*A*_ value, that can be transformed into a > simple type if > necessary. Complex "values" are stored as child configuration > elements--and > nothing else. In fact, if a Configuration object has children > AND a value, it > is technically in error.
See below. > I don't see the usefulness of making the > Configuration object into a DOM. And I am not suggesting this. I am suggesting, however, that the primitive types one can store as values should be extended with a DOM node type. The DOM should not be traversable via the Configuration interface. What I am talking about is a getValueAsDOM () method. It is the _value_ that is the DOM node. The configuration node has no children. Regarding resource usage: If you do not store any DOM nodes in the configuration the overhead is zero. If you do, you pay on a per-node basis. That price may be high, but as we both know it is rarely paid. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
