[jdom-interest] Text class (Modified)

[Steven D. Keens]

As you well know a CDATA is unparsed which allows you to use all those
special XML characters like < and > within.  If you use an isCDATA() method
then there has to be some way of determining if the internal representation
is well formed before outputting it to XML file or stream.  There are a
couple of options here:
1) Text has a boolean that is set when the Text object is set.  This
requires parsing the input looking for those special XML characters and also
wastes memory.  More often than not Texts will NOT be CDATA.
2) Parse the internal representation on the fly in isCDATA().  This can be
quite slow.

Have I forgotten something?

--
Steven Keens                mailto:skeens at planetfred.com
Planetfred Inc.             http://www.planetfred.com
44 Byward Market, Suite 240, Ottawa, ON, K1N 7A2, Canada

The most exciting phrase in science, the one which heralds
new discoveries, is not "Eureka!", but "That's funny!"
                       -- Issac Asimov


>-----Original Message-----
>From: jdom-interest-admin at jdom.org
>[mailto:jdom-interest-admin at jdom.org]On Behalf Of
>philip.nelson at omniresources.com
>Sent: Monday, May 28, 2001 12:34
>To: jdom-interest at jdom.org
>Subject: RE: [jdom-interest] Text class (Modified)
>
>
>
>> >public class Text {
>> >
>> >     private StringBuffer value;
>> >     private Element parent;
>> >
>> >     protected Text() { }
>> >
>>
>> I guess I've never really understood why JDOM has these protected
>> noargs constructors. A subclass of a Text is still a Text, and should
>> still be able to rely on all the other public methods in the Text
>> class. These methods will fail unexpectedly if this constructor is
>> used. Why do we need this constructor at all. Why can't subclasses
>> use the normal public constructor that does ask the caller to provide
>> a String?
>>
>> Same question for the other constructors like this in the
>> other core classes.
>
>It allows you to basically start over with your subclass and just use the
>interface of the base class.  Without this constructor, I can't be
>sure that
>a change in the subclass won't affect my totally rewritten subclass.  It
>also gives you, in the case of JDOM anyway, an almost abstract interface to
>implement.  Since the member variables are not assigned, it's pretty close
>to having an interface to work with.
>
>I am not so sure private member variables make sense.  We have
>been somewhat
>inconsistent with this but I think a subclass friendly base class will have
>protected members.  We do this in Element and Attribute but not in
>SAXHandler for example.
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youradd
r at yourhost.com