W3C home > Mailing lists > Public > www-dom@w3.org > April to June 1998

Re: critique of WD-DOM-19980416

From: Justin Wells <reader@semiotek.com>
Date: Sat, 27 Jun 1998 20:54:05 -0400
Message-ID: <19980627205405.22998@fever.semiotek.com>
To: Justin Wells <reader@semiotek.com>
Cc: www-dom@w3.org

Comment on the Text object:

One of the methods of the Text object is not like the others. 

All but one perform operations on the underlying text: adding 
data, setting data, appending it, inserting it, getting it, 
and deleting it. 

Splice, however, performs operations on the surrounding nodes 
in the tree. 

It seems somewhat out of place, since it has more to do with 
the structure of the document as a whole than it does with the 
text object itself.  

I don't believe that the Text object should take responsibility 
for the structure of the whole document.

It would probably be better to write a set of DOM utility classes
capable of performing common operations on a DOM implementation, 
and then ensure that the underlying DOM objects have enough 
capabilities that the utility classes can be implemented 

So I would modify Text as follows:

  -- remove the splice method as it stands now
  -- add the following methods:

         * Remove count characters beginning at offset and 
         * return them as a Text object
       Text Text::splice(int offset, int count); 

         * Return the number of characters contained in this object
       int Text::length();

  -- Implement a utility class to splice objects as follows:

       void Utility::splice(Element newElem, Text orig, int offset, int count) :
           Text left = orig.splice(0,offset);
           Text right = orig.splice(count, orig.length());
           Element parent = orig.getParentNode();

This keeps the Text class simple, and provides methods which may actually be 
more generally useful. It also allows the structural splice() operation to 
be performed efficiently from a library class. 

Moving higher-level operations like splice() into a library, and providing 
a simple yet useful interface to each low-level class is preferable to 
loading a whole bunch of unrelated responsibilities on lower level classes.

Received on Saturday, 27 June 1998 20:53:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:04 UTC