[jdom-interest] insertChild in Element

[trebor.a.rude at lmco.com]

	I agree that the getting functions should stay, since they have no
useful equivilents in the List API, but the addContent/removeContent
functions do have equivilents in the List API (and the add functions of the
PartialList can be changed or overloaded so they only accept JDOM nodes, as
the current addContent functions do), which is why I mentioned maybe
removing them. Being common isn't so much of an issue for a pre-1.0 API.

	As for the namespace issue, it seems reasonable to me, but I don't
really have enough experience with namespaces (or even the relevant
standards) to make much of a comment on it.

Trebor A. Rude
trebor.a.rude at lmco.com

> -----Original Message-----
> From:	David W. Smiley [SMTP:dsmiley at mitre.org]
> Sent:	Thursday, August 31, 2000 9:50 AM
> To:	trebor.a.rude at lmco.com; jdom-interest at jdom.org
> Subject:	Re: [jdom-interest] insertChild in Element
> 
> trebor.a.rude at lmco.com wrote:
> > 
> > So which would you prefer?  If I had to choose, I'd say go with the
> current
> > implementation and in fact maybe even get rid of the existing
> > addContent/removeContent functions that are currently in Element (except
> > maybe for the ones that deal with the text content), so that all
> > manipulation of the children is through the List. The user can choose
> > between getChildren() and getMixedContent() depending on if they want
> just
> > the Element children or all of them.
> > 
> > Trebor A. Rude
> > trebor.a.rude at lmco.com
> 
> Agreed; that would be consistent.  Having an "Element.addContent" and
> "Element.getChild" (with all overloaded variations) should remain,
> however, since they are just so common.  This issue is paralleled with
> that of attributes.
> 
> On the side... I like the idea that Eric Galluzzo has in which elements
> added and obtained default to the namespace to that of the parent
> element.  That is intuitive and promotes the idea of scope.  After all,
> in my Java code I certainly don't use fully qualified package names for
> classes in the same package as I'm writing :-).
> 
> -- Dave Smiley
>