[jdom-interest] XMLOutputter to the rescue (get/setText)

[guru at stinky.com]

=== on element.getText() (not setText or XMLOutputter) ===

I'm warming to Elliotte's recursion idea, though I am still jittery
about an element needing to access many other elements during what
should be a simple accessor.  This could lead to big inefficiencies.

For instance, instead of appending to a single StringBuffer, the naive
implementation will waste at least one String and one StringBuffer per
child, plus the exponentially extra time to copy and recopy.  This is
why I'd like to use XMLOutputter -- it uses a single stream (Writer),
and if that's a StringWriter, then there's just a single recopy at the
very end of the process.

So!  

On the proposal that getText recurse through child elements:

PRO:
 - returns more sensible output for mixed content
 - *doesn't* affect behavior in the simple case for unmixed content

CON:
 - violates principle that an accessor method should stay in the
   object what brung it
 - inefficient implementation
 - you can already get recursion via XMLOutputter if you really want it

Is that it?

On Thu, Jul 12, 2001 at 11:20:28AM -0400, Elliotte Rusty Harold wrote:
> >  <group>
> >    <entry>fred</entry>
> >    <entry>jim</entry>
> >  </group>
> >traversing in a composite like way I find a node with "fred..jim" and nodes
> >with "fred" and "jim"

getText with recursion: "\n  fred\n  jim\n"
getText without recursion: "\n  \n  \n"

I think Rusty is right; the output is more sensible with recursion.

> 
> If they ask for the text of a group, they get the text of that group. If they ask for the text of an entry they get the text of that entry. 
> 
> The question here really is predictability. If somebody does ask for the text of group what do they expect to get? a string full of white space? or "
>     fred
>     jim
>   "? I think it's the latter. They may be marginally surprised by the line breaks, but that's easy to notice and normalize if it's a concern. 
> --