W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2001

Re: Type-safe iteration over the DOM in DOM 2 & 3?

From: Gareth Reakes <gareth@decisionsoft.com>
Date: Tue, 20 Mar 2001 08:55:57 +0000 (GMT)
To: Peter Meyer <petermeyer99@hotmail.com>
cc: www-dom@w3c.org, www-dom@w3.org
Message-ID: <Pine.LNX.4.21.0103200855290.2471-100000@localhost.localdomain>
Do NodeIterator or TreeWalker not do what you want?


Gareth


On Mon, 19 Mar 2001, Peter Meyer wrote:

> Hello DOM-World,
> After working for a while with DOM2 and looking over the spec of DOM3, it 
> still seems that there is no way to perform a truly object-oriented 
> traversal of a DOM tree. Using the existing model, I can not see a way to 
> traverse the DOM without actually using a switch statement based on node 
> type.
> 
> This seems to me a fairly non-scalable, hard-to-maintain and inelegant way 
> to traverse a tree of objects. I am sure it has been considered by the W3C 
> to add the ability to use a visitor pattern or a similar object oriented 
> design pattern for traversal to the node interface. I would like to 
> understand why it has been decided against such an addition.
> 
> Given that the DOM is also used in many XML applications, the ommission of a 
> good object oriented mechanism is particularly problematic.
> 
> In such an application it is likely that a class factory is used to create 
> particular subclasses specific for each element type, providing specialized 
> functionality for the application actually building the DOM from an XML 
> file. Using a switch statement to call specialized functionality on 
> traversal is, in my humble opinion, a very unsatisfactory way of action. Yet 
> with the current DOM design there seems to be no alternative.
> 
> Please consider the addition of a simple visitor pattern interface to the 
> node interface. After all, it is an extremely simple addition that can 
> safely be ignored by anybody who does not desire to use it, yet permits to 
> use the DOM as a primary configurable data structure in a larger scale OO 
> application.
> 
> Thanks!
>    PM
> 
> 
> 
> 
> 
> 
> 
> P.S:
> The visitor interface would require:
> 
> In the node interface:
> A method
> accept(IVisitor v);
> 
> A new interface IVisitor which contains one method:
> execute(Node n);
> 
> Implementations:
> In a reference implementation of a class that implements the node if, this 
> function would just be like this:
> public void accept(IVisitor v)
> {
>     v.execute(this);
> }
> Subclasses of nodes that have children would additionally call
> accept(v);
> for each of their children.
> 
> Implementors of the IVisitor interface would implement overrides for execute 
> that take as an argument the particular subclass of the node interface they 
> are interested in.
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> 

-- 
Gareth Reakes, Lead Software Engineer  
DecisionSoft Ltd.            http://www.decisionsoft.com
Office: +44 (0) 1865 203192
Received on Tuesday, 20 March 2001 03:55:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:48 GMT