Overriding isNodeAfter is definately what you want to do, in any case.
> There is this while loop at the end of the function
Actually it's a do loop with a while test at the end (the formatting does
make it look like a empty while loop). The check is to make sure we don't
have duplicate nodes or nodes that are found that have been already found.
The test is:
}
// Not sure what is going on here, but we were loosing
// the next node in the nodeset because it's coming from a
// different document.
while (
(DTM.NULL != nextNode) && (DTM.NULL != m_prevReturned)
&& getDTM(nextNode).getDocument() ==
getDTM(m_prevReturned).getDocument()
&& getDTM(nextNode).isNodeAfter(nextNode, m_prevReturned));
...which sure looks ugly as sin. I'm not certain that I need all these
checks any more, so I'm going to try playing around with this.
-scott
John Gentilin
<johnglinux@eyecatch To: [EMAIL PROTECTED]
ing.com> cc: (bcc: Scott Boag/CAM/Lotus)
Sent by: Subject: Re: FilterExpr less
sorting for SQL & other uses (was Re:
[EMAIL PROTECTED] [Bug 2925] - Parameterset from DOM
Node, broken)
tching.com
08/07/2001 08:22 PM
Please respond to
xalan-dev
Scott,
It looks like it may work. I think that AxesWalker#nextNode() is
getting confused because the node identity from row to row is the
same. There is this while loop at the end of the function that seems
to be causing the problem although I can't see the problem with the
logic. I will modify isNodeAfter() to compensate as a test.
Any other ideas ??
JohnG
[EMAIL PROTECTED] wrote:
> Hi John. OK, I think I have this working pretty well. I did a test with
> the mkay stylesheet and it does not seem to be sorting the nodes any
> longer.
>
> >From the commit note:
> Added isDocOrdered() and
> getAxis() to both DTMIterator and AxesWalker, and implemented
> appropriate overloads in derived or implementing classes. In
> FilterExprWalker
> return the contained DTMIterator's getAxis(). In WalkerIteratorSorted,
> implement canBeWalkedInNaturalDocOrder() function that is called
> from setRoot(...). If this function returns true, than don't sort the
> nodes
> in setRoot, and in all other respects treat this as if it is a simple
> WalkingIterator.
>
> So, in effect, the WalkingIteratorSorted is doing a second-tier runtime
> check to see if it really should be sorted, based on runtime information.
> While this adds some expense to WalkingIteratorSorted#setRoot, I'm hoping
> it will be made up easily in general stylesheets by doing less node
sorting
> and caching.
>
> Please let me know what you think.
>
> The next step is to somehow throw an error if an XPath does occur where
> sorting is done. Can you easily determine that from the SQL extension?
(I
> just don't see how this check can easily or even not-so-easily be done at
> stylesheet build time.)
>
> -scott
