You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by MA...@dstsystems.com on 2003/04/08 23:04:28 UTC

Another question on DOMTreeWalker

Ok, I've got another question on DOMTreeWalker. BTW, thanks Gareth for the
info on DOMTreeWalker vs. DOMNodeIterator.
So, I'm using a DOMTreeWalker to go through the nodes in a tree.  I've
created it with this statement:
  DOMTreeWalker *tree = mDoc->createTreeWalker( mElement,

DOMNodeFilter::SHOW_ELEMENT,
                                                &filt,
                                                false );

mElement is a DOMElement, filt is my filter object, derived from
DOMNodeFilter, and mDoc is a DOMDocument. All this is lovely.  The problem
is, the tree walker I get seems to ignore the whatToShow paramter.  When I
set a break point in my filter's acceptNode method, I'm seeing DOMText
nodes as well as DOMElement nodes.  Since my filter code was assuming that
it would only get DOMElements, I was casting the DOMNode pointer passed in
to a DOMElement. Obviously, when it wasn't, bad things happened after that!
I've looked at the code for DOMTreeWalkerImpl, and it seems like it should
work, which makes me think I must be doing something wrong somewhere else,
but I can't see it!  I've got a reasonable workaround, all my filters now
make sure they're dealing with the type of node they expect, rather than
assuming thats the case, but based on the documentation, I shouldn't have
to do that.  Any ideas??

I'm using version 2.2.0, on Windows 2000, built( myself ) with Visual
Studio 6.0


Marc Robertson
Staff Consultant
AWD Development
DST Systems, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org


RE: Another question on DOMTreeWalker

Posted by Erik Rydgren <er...@mandarinen.se>.
Well it looks like the code is behaving as you say.
Assuming you are at the position in a tree with a text node.
Lets walk through the code...

short DOMTreeWalkerImpl::acceptNode (DOMNode* node) {

    if (fNodeFilter == 0) { // This is false in your case, you have a node
filter
        if ( ( fWhatToShow & (1 << (node->getNodeType() - 1))) != 0)
        {
            return DOMNodeFilter::FILTER_ACCEPT;
        }
        else
        {
            return DOMNodeFilter::FILTER_SKIP;
        }
    } else {
        // REVISIT: This logic is unclear from the spec!
        if ((fWhatToShow & (1 << (node->getNodeType() - 1))) != 0 ) { //
This is false, you have SHOW_ELEMENT only
            return fNodeFilter->acceptNode(node);
        } else {
            // what to show has failed!
            if (fNodeFilter->acceptNode(node) ==
DOMNodeFilter::FILTER_REJECT) { // Here your filter is called. If you reject
the node it will be rejected, otherwise it is skipped.
                return DOMNodeFilter::FILTER_REJECT;
            } else {
                return DOMNodeFilter::FILTER_SKIP;
            }
        }
    }
}

The answer: You'll have to check the nodetype in your filter.
I did read up on the W3C DOM Core 2 Traversal recomendation. And It looks
like Xerces conforms to the spec:

whatToShow of type unsigned long, readonly
This attribute determines which node types are presented via the TreeWalker.
The available set of constants is defined in the NodeFilter interface. Nodes
not accepted by whatToShow will be skipped, but their children may still be
considered. Note that this skip takes precedence over the filter, if any.

Looks like the supplied filter should be called for all nodes, but the
whatToShow filter takes precedence. But it is not waterproof. The author
might have meant that if the whatToShow skips the node then it will take
preceedence and the nodeFilter should not be called at all. But my vote is
on the interpitation that actually is implemented. How should you otherwise
be able to reject whole subtrees if whatToShow is set to SHOW_TEXT?

Regards

Erik Rydgren
Mandarinen systems AB
Sweden


-----Original Message-----
From: MARobertson@dstsystems.com [mailto:MARobertson@dstsystems.com]
Sent: den 8 april 2003 23:04
To: xerces-c-dev@xml.apache.org
Subject: Another question on DOMTreeWalker


Ok, I've got another question on DOMTreeWalker. BTW, thanks Gareth for the
info on DOMTreeWalker vs. DOMNodeIterator.
So, I'm using a DOMTreeWalker to go through the nodes in a tree.  I've
created it with this statement:
  DOMTreeWalker *tree = mDoc->createTreeWalker( mElement,

DOMNodeFilter::SHOW_ELEMENT,
                                                &filt,
                                                false );

mElement is a DOMElement, filt is my filter object, derived from
DOMNodeFilter, and mDoc is a DOMDocument. All this is lovely.  The problem
is, the tree walker I get seems to ignore the whatToShow paramter.  When I
set a break point in my filter's acceptNode method, I'm seeing DOMText
nodes as well as DOMElement nodes.  Since my filter code was assuming that
it would only get DOMElements, I was casting the DOMNode pointer passed in
to a DOMElement. Obviously, when it wasn't, bad things happened after that!
I've looked at the code for DOMTreeWalkerImpl, and it seems like it should
work, which makes me think I must be doing something wrong somewhere else,
but I can't see it!  I've got a reasonable workaround, all my filters now
make sure they're dealing with the type of node they expect, rather than
assuming thats the case, but based on the documentation, I shouldn't have
to do that.  Any ideas??

I'm using version 2.2.0, on Windows 2000, built( myself ) with Visual
Studio 6.0


Marc Robertson
Staff Consultant
AWD Development
DST Systems, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org