Oops, read my mail boxes out of order. Will try the overload
and get back to you.
[EMAIL PROTECTED] wrote:
> 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
--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546
Contact Info
[EMAIL PROTECTED]
Phone 1-510-881-4821
--------------------------------------
