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

No... See my answer to the other mail in this thread... These functions only 
allow me to traverse the data structure, but I still need to rely on 
compile-time field information to manually dispatch functionality, instead 
of using the polymorphism of the language runtime to handle it for me in a 
type-safe manner. If you don't subclass your DOM classes heavily and 
dynamically, it probably does not matter, but if you do, it does not lead to 
nice code.



>From: Gareth Reakes <gareth@decisionsoft.com>
>To: Peter Meyer <petermeyer99@hotmail.com>
>CC: www-dom@w3c.org, www-dom@w3.org
>Subject: Re: Type-safe iteration over the DOM in DOM 2 & 3?
>Date: Tue, 20 Mar 2001 08:55:57 +0000 (GMT)
>
>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
>
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Received on Tuesday, 20 March 2001 14:09:11 UTC