[jdom-interest] setText() to replace children?

[Alex Chaffee]

At 6:27 PM -0500 7/9/01, Brett McLaughlin wrote:
 >
 >>One item in the TODO file:
 >>
 >>* Consider if setText() should not replace children
 >>
 >>I think setText() should set the text of the element, removing any other
 >>text in the element. However, I don't think any other children (such as PIs,
 >>comments, etc) should be affected. Does anyone agree/disagree?

This leaves the behavior ambiguous. Should the existing children be moved to 
the front, or the end?  What happens to whitespace between two comments?

The current behavior is unambiguous. "This sets the content of the element 
to be the text given. All existing text content and non-text context is 
removed." Anyone who wants to preserve existing content can play with their 
own lists (much more intelligently than we can).

Elliotte Rusty Harold wrote:
 > I disagree. It should either replace all content or throw an exception. 
But it shouldn't replace just some part of the content.
 >
 > Actually, here's an idea: suppose we remove setText() completely and 
replace it with this overloaded method:
 >
 > public Element setContent(String text)

This name would be fine with me, since it reinforces that all content will 
be removed.

In fact, it opens the door to a new set of polymorphic methods, just like 
with addContent:

   Element setContent(Comment comment)
   Element setContent(Element element)
   Element setContent(EntityRef entity)
   Element setContent(ProcessingInstruction pi)
   Element setContent(String text)

to go with

  Element setContent(List content)

all of which replace the entire content of the element.

I think that is natural, and will make up for the loss of setText.

Alex Rosen wrote:

> The only problem with all these proposals is the lack of symmetry. If you get
> text by calling getText(), it's natural to set it via setText(), and if that's
> not the name of the method, you have to go looking for it, and figure out if it
> really does what you want it to do. Similarly for setContent() and
> setChildren(). Whether that's a good enough reason to keep the current state of
> things, I don't know. I really like the intuitiveness of setText(), though. In
> the common case where you don't have mixed content, it feels a lot more
> natural.


I think the API lost nomenclature symmetry a long time ago :-) (see any 
thread on "getChildren").

getText() isn't really an accessor though.  There is no property of Element 
called "text."  Rather, it's a utility method that iterates through content 
and concatenates some children while throwing others away.  At best you 
could think of it as a read-only, derived property. Hence there should be no 
setText method, reinforcing that it's a read-only property.

I share Alex's intuition about setText though.  It's just a nice name for 
the method. However, with its other setContent friends it won't be lonely 
with its new name :-)

-- 
Alex Chaffee                       mailto:alex at jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/