I think that there is a simple answer here: If you want your xpath to
try to match in the face of deletions, you set `rerunxpath`. If you
don't have that on, and you delete the node that was matched, you
should get `null`. _Maybe_ the intent of the original author was that
if you have a nextSibling and delete yourself then even without
rerunxpath you can figure you ought to now bind tothe next sibling,
but that's really not accurate [you could certainly construct an xpath
expression that would _not_ match if rerun were on].
Bottom line: I agree if you delete yourself and don't have rerun on,
you should be null. (Which means the documentation and test case need
to be revised. Which means you are proposing an API change...)
My 2p.
On 2009-04-03, at 19:57EDT, Henry Minsky wrote:
Hi Laszlo Users,
This was discussed previously in a thread in Laszlo-Dev, but we
realized we
should probably get people's opinion
from Laszlo User before deciding on the 'correct' behavior. I need to
resolve this bug by either changing
the regression test to match the current behavior or changing the
behavior
of the deleteNode method back to the
older behavior.
The bug is http://www.openlaszlo.org/jira/browse/LPP-7461
And was discussed on laszlo dev back in December:
http://www.openlaszlo.org/pipermail/laszlo-dev/2008-December/018410.html
Currently, the documentation says
datapointer.deleteNode();
Removes the node pointed to by the datapointer. If rerunxpath is
true and
xpath has been set, it will be re-evaluated. Otherwise, if the
deleted node
has a following sibling, the pointer is repositioned at that sibling.
Otherwise the pointer is set to null.
However, the current behavior actually will back up the pointer to a
previous sibling if there is no next sibling.
--
Henry Minsky
Software Architect
[email protected]
