Re: Comments and questions on text node interface

Stefan Wachter wrote:

> Dear all!
>
> I have comments and question regarding the following 
> attributes/methods of the text node interface:
>
> 1. wholeText attribute:
>
> What is the expected use case of this attribute? Shouldn't this 
> functionality moved to the parent, because it is quite similar, to the 
> textContent attribute of the node interface? If this functionality is 
> really needed then I propose to have a method on node:
>
> /**
> * Collects the text content of all logically-adjacent text nodes of 
> the specified text node.
> */
> public String getWholeText(int anIndex);   // alternatively: 
> getWholeText(Text aTextNode)

The expected use is when you are trying to get an infoset or XPath view 
of the text pieces.

It is difficult to get an index number if you have a text node, short of 
going back and manually counting, which would make the method more 
trouble than it is worth.  An index does not work well at all if there 
are entity references involved in which case you have multiple hierarchy 
levels involved.  It is not clear what is the value of greatly 
complicating the signature and invocation and making it a method on an 
ancestor would be.  Just finding the proper ancestor to call it on would 
be a multistatement loop -- painful since the point of the method was 
convenience.  It also gives the possibility to call it
incorrectly in many different ways.  I also do not believe that it is 
appropriate to add a method this specific to text data to Node.

> 2. replaceWholeText method
>
> This method has a lot of tree-processing logic that should not be 
> executed by a child node on its parent node. I would prefer the parent 
> node to have control over the process. Therefore I propose a method on 
> the node interface:
>
> /**
> * Replaces the logically-adjactent text nodes always by a NEW text node.
> */
> public Text replaceWholeText(int anIndex); // alternatively: 
> replaceWholeText(Text aTextNode); 

See the above objections to using an index and the more-complex signature.

> 3. splitText method
>
> To be consistent I would also move this method to the node interface too.
>
> In general I think that the DOM core should not contain too much 
> special-purpose functionalites like these once. In addition I assume 
> that this attribute and these methods are meant for editing. Therefore 
> they should be moved from the DOM core to the NodeEditAS interface.

The NodeEditAS interface has nothing to do with editing a document.  It 
has to do with editing an abstract schema.  Your suggestion that it 
should belong on node goes against the precedent of DOM 1 and 2 which 
places text editing methods on specific interfaces, such as 
CharacterData.  SplitText itself is already a part of the Text interface 
in DOM Level 2.  I cannot see why it does not belong there, but I didn't 
see the argument for wholeText / replaceWholeText either.

Perhaps some users might need an extra warning that nodes outside of the 
target node may be accessed or modified, but I think this is obvious 
from the description, and from the fact that this is a text node which 
is always a leaf node, so the minute you talk about other nodes you 
cannot possibly be talking about descendants.  I do not see any problems 
with the current level 3 proposal and level 2 recommendations.

Ray Whitmer
rayw@netscape.com

Received on Thursday, 14 March 2002 07:42:47 UTC