[jdom-interest] Important proposal: Element/Document changes

[tsasala at hifusion.com]

Jason Hunter wrote:
> 
> tsasala at hifusion.com wrote:
> >
> >         Two comments:  is it possible to deprecate the methods instead
> > of removing them?  We have application code that relies on JDOM, despite
> > the fact it is beta :).
> 
> I personally would be OK with deprecating for one beta round to give you
> time to change.  However, I'm firm there will be NO deprecated methods
> present in 1.0 final.
> 

	That's perfectly reasonable.


> > Secondly, how about a replaceChild or at least
> > an addChildAt method?  It's trivial, but order makes a huge difference
> > to our application, so removeChild/addChild just doesn't work.
> > Other than that, I'm generally in favor of the changes.
> 
> I can see a good use case for replaceChild() for tools like XMLC that do
> that all the time.  Would it be replaceChild() or replaceContent()?  I
> lean toward replaceChild(Element,Element).  replaceContent() would need
> 5*5 versions depending on what you wanted to replace with what.
> Replacing an element with an element is probably the far more common use
> case, and that should be called replaceChild().
> 
> Then the other method you propose would be addContentAt().  That's
> probably better as a Content form rather than Child form.  Hmm, we'd
> need five forms again to cover all bases.  What's the compelling common
> use case here?

	The fundemental idea here is to replace the element in the 
backing list with a new element in exactly the same place.  replaceChild
makes more sense to me, as I don't need to know the index of the element
in the parent's list.  However, addChildAt might provide more flexibility
in the long run.  If I had to vote, I'd vote for replaceChild.
FWIW, I have the code implemented as a static helper now, so I can
send it along if need be.

	-Tom