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

Elliotte Rusty Harold elharo at metalab.unc.edu
Tue Jul 10 11:06:40 PDT 2001


At 1:12 PM -0400 7/10/01, Alex Rosen wrote:
>Argh! Once again, the conflict between data-oriented and document-oriented XML
>rears its head.
>
>I propose one thing: if your XML uses (or can use) mixed content, you should
>*NOT* be calling getText() or setText() or whatever we call them. 

If the method won't work we shouldn't provide it. Don't load bullets into guns, give them to users, and say "Go ahead, pull the trigger, I'm wearing a bullet proof vest." They may miss and hit the person next to you who isn't decked out in Kevlar. 

>Using mixed
>content is complex, and I think that trying to make these methods work better
>for mixed content will only end up making them worse. For the non-mixed content
>case, the get/setText() and get/setChildren() methods are really convenient,
>but in the mixed content case they just sweep too much important information
>under the rug.

Properly implemented nothing gets swept under the rug. I don't understand your objection here. 

>I think that your proposed change has the same problems. It works well for your
>example, but it will lull users into using getText() for mixed content, when I
>believe they should not. If the XHTML gets more complex, then your proposed
>solution falls apart. For example, in the XHTML "<p>ONE</p><p>TWO</p>", the
>whitespace value of getText() would probably not be what you're looking for.

Can you elaborate? I don't see any problem at all here. 

>What if the XHTML contain a <ul> element or a <table>? 

Asking for the value of a ul returns the complete text content of the ul. Asking for the value of a table returns the complete text content of the table. Asking for the value of a foo returns the complete text content of the foo. 

Invoking getText() on a method returns the complete text content of the element. in the correct order. All white space is preserved. All entity references and CDATA sections are converted to the appropriate string values. All comments, processing instructions, and tags are stripped. This is how the value of an element is defined in XPath. What's wrong with this? 

> Are we leading people
>down the wrong path if we make it work for the simple cases but not for the
>more complicated ones? I think we should keep things as-is.
>

My solution works for ALL cases, simple and complicated. Right now it only works for the simple cases. That's what I'm proposing we change. 
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+ 
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      | 
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |
+----------------------------------+---------------------------------+



More information about the jdom-interest mailing list