[jdom-interest] Still to do - Text 'merger'

Rolf Lear jdom at tuis.net
Tue Apr 3 09:19:56 PDT 2012

I realize that the conditions under which you get these 'adjacent' Text
items are limited. Essentially, the only way to do it is through the
programming API.... oh, and, I guess technically the StAX streams could do
it. But, I mostly expect this to be a problem with people having JDOM code
adding Text content, and then being surprised when they want to retrieve it
and have to figure out which one... or all of them to process. The
Outputter variants already all (since JDOM 2.x) merge the adjacent Texts in
to a single 'event' or whatever... so output is not a problem either

I am really not sure how big the problem is... but the other thing my
current code example does is to remove Text items which are empty (new
Text("")).... and that is not something that addText() would accommodate...

All this process would solve is that one time when someone has somehow got
multiple texts, and they want to simplify the processing of the JDOM tree.
A non-recursive example would be

for (Element emt : doc.getDescendants(Filters.element())) {

When I look at it like that, it's really simple....

I think my opinion is swaying to either:
1. don't do it at all - but I have the code done already, and even though
it is simple, it is *very* useful in a *limited* situation. Hate to waste
10-lines of code ;-)
2. do it as a non-recursive 'cleanup' post-process task.... like the
mergeAdjacentTexts() example above.

I think while adding an 'append-or-create' Element.addText() would be
somewhat useful at reducing the problem, it does not solve it after it


On Tue, 3 Apr 2012 10:38:05 -0500, "Bradley S. Huffman"
<bshuffman at gmail.com> wrote:
> Why not just a Element.addText(String) that either adds a new text
> node or merges with a adjacent one if one exists?  I don't think a
> recursive merge method would be that useful since SAXHandler already
> does it in the characters() method.

More information about the jdom-interest mailing list