> -----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]
