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