[jdom-interest] Text class in the api

[Paul Libbrecht]

There should be a big warning here on release time because a lot of code 
using getContent may have been written expecting "String" types !! Or are 
you still keeping the philosophy of making things with "String" types (as 
a kind of option builders) ??

Oh, and by the way, my best way to make an efficient text-with-append is a 
global buffer, using javax.swing.text.GapContent, We can, sadly, not 
assume this class to be reachable in all distributions.
The use is for a visual editor where typically inserts are performed a lot 
of times after the JDOM document is built. Subclassing Text class and 
JDOMFactory is a must for this task once that'll be put in the 
distribution. Currently, I use my own little modifications (JDOMFactory, 
SAXHandler, XMLOutputter, didn't go DOM in and out yet).

It would be nice to collect other subclassing patterns somewhere, 
something like Greg Guerin's "What you can do with this library" texts 
(http://www.amug.org/~glguerin/sw/).

Paul


On Jeudi, octobre 25, 2001, at 08:53 , Christian Knorr wrote:
>> I'd say this a little differently - an Element has Text nodes, not > > 
>> String
>> nodes. But we will keep the convenience methods that can return the
>> Element's value as a String, concatenating all the characters from all > 
>> its
>> Text nodes together. So get*Text*() and setText() stay, but
>> addContent(String) and removeContent(String) are replaced by Text > > 
>> versions.
>
> This sounds good to me from a user's point of view. If there really is a
> need for a text class keeping the String methods getText() and setText()
> is essential for JDOM's philosophy of simplicity and ease of use.