Approved.
I wonder if it could have a better name that reflects the fact that it
is actually calculating the xpath index of the node in it's parent?
On 2008-06-24, at 13:09 EDT, Henry Minsky wrote:
Change 20080624-hqm-Y by [EMAIL PROTECTED] on 2008-06-24 13:00:25 EDT
in /Users/hqm/openlaszlo/trunk4
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: support datapath iteration workaround from dguide example
New Features:
Bugs Fixed: LPP-6282
Technical Reviewer: ptw
QA Reviewer: pbr
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details:
The example mentioned in LPP-6282 from the docs describes a
workaround for
recomputing an xpath after it gets nulled out by the selectNext/
selectPrev
selectors.
+ The workaround depended on a LzDatapointer.getNodeOffset, method
that
was deprecated, and removed recently. This patch puts it back and
makes it public.
The deprecation comment in LzDatapointer.getNodeOffset used to say use
xpath "position()" operator instead, but that does not work in this
case because the xpath no longer exists, and the app code is trying to
reconstruct it.
+ This patch removes the LzReplicationManager.getNodeOffset method,
because it had a conflicting semantics (it takes a node pointer,
whereas the LzDatapointer.getNodeOffset does not), and there don't
seem
be any callers. (Of course, that is why LzDatapointer.getNodeOffset
got
deprecated, so maybe this will cause the same kind of trouble)
Tests:
attached to bug report
Files:
M WEB-INF/lps/lfc/data/LzReplicationManager.lzs
M WEB-INF/lps/lfc/data/LzDatapointer.lzs
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080624-hqm-Y.tar
