|
|
Re: 2 bugs in 'delete'?: msg#00068
|
Subject: |
Re: 2 bugs in 'delete'? |
Paul Miniato wrote:
Hi Joern,
thanks. Sorry about the namespace issue.
Regarding your points 2 and 3, yes, I should have been more explicit
with comments. These were expected to delete nothing (and return
good status) and this is now what they do (as of 0.9.5).
Regarding
1] <xf:delete xf:nodeset="/top/middle[position()=2]" xf:at="1" />
With 0.9.5 this appears to delete the same node as the first button,
i.e.:
<xf:delete xf:nodeset="/top/middle" xf:at="1" />
(the field containing "My data 1")
I would have expected that the nodeset for the first delete would
only include "My data 2" and thus "My data 1" could not possibly be
deleted by #1. Perhaps my understanding of XPath context is flawed,
or is something else going on here?
in my understanding of XPath context the nodeset attribute only sets the
context against which the at expressions is evaluated. so it does not
really select a nodeset here but a context-node in the nodeset. - but
i'm also not 100% sure about this interpretation cause when re-reading
the spec there's no mention of a context node for insert action...
Joern
Thanks, Paul M
joern turner wrote
hello Paul,
there were different issues.
first, there was a small problem with your testform. it forgot to
fix the namespace as empty on instance (xmlns=""). this resulted in
part of the mishaviour. but it actually brought up another silly
bug i made during my last 'fix' which is fixed now.
but there's something to mention about some of your cases
1] <xf:delete xf:nodeset="/top/middle[position()=2]" xf:at="1" />
this will delete (IMO correctly) the first node in the nodeset.
nodeset only sets the context node for this operation and cause
this exists the node at position 1 (the 'at') is deleted.
2] <xf:delete xf:nodeset="/top/middle[position()=4]" xf:at="1" />
here the context node does not exist and therefore nothing happens.
3] <xf:delete xf:nodeset="/top/middle[optional]" xf:at="1" /> same
as above. context node does not exist.
hope this meets your expectations too.
Joern
Paul Miniato wrote:
Hi Joern,
thanks. We're heading in the right direction. :-)
Unfortunately with Chiba 0.9.5, delete still seems to have some
problems. (I am aware of your recent fix to the logging of an
error message even when the node exists.)
As the attached example shows, there still appears to be a couple
of problems:
1.) It looks like attempting to delete the 2nd or subsequent
member of a selected nodeset doesn't delete anything. (Only the
1st works, as far as I can tell.)
2.) It looks like when you restrict the nodeset to a
non-head subset
of the repeat group, and then delete its first element, the first
element of the repeat group (which was NOT in the selected
nodeset) is the one that disappears. Odd.
I may have time to look into the mechanics of this later, but I'm
posting this much for now.
Thanks, Paul M
joern turner wrote
Hello Paul,
i've setup a testcase that uses your form and fixes the
behaviour like this:
all three actions now return 'good', means that delete never
cancels the action flow.
i've also added the case the index is '0' and asserted that the
index value is not changed by these illegal actions.
Paul Miniato wrote:
Hi,
this may turn out to be another one of those XForms "spec
interpretation bugs", but I hope not. I think it would be
easy to "fix".
The attached example shows delete actions that appear to
misbehave.
1.) Delete None is using a "nodeset" that selects no nodes.
According to <
http://www.w3.org/TR/xforms/slice9.html#action-delete
"If the collection is empty, the delete action has no
effect." It
appears that
org.chiba.xml.xforms.action.deleteAction.perform() is
returning false in this case, causing the enclosing action to
be stopped prematurely.
2.) Delete Last is using an "at" that is beyond the size of
the selected nodeset. This one I'm not sure about. <
http://www.w3.org/TR/xforms/slice9.html#action-delete > seems
to imply that "at" might be treated the same way for delete
as
it is for
insert. At <
http://www.w3.org/TR/xforms/slice9.html#action-insert >
it says "If the resulting index is outside the valid range of
the node-set, it is replaced with either 1 or the size of the
node-set, whichever is closer." I know in the delete section it
goes on to say, "If no nth node exists, the operation has no
effect." However, this might be looked at as merely a
reiteration of "If the collection is empty, the delete action
has no effect." So perhaps one could infer that Delete Last
should delete the last item even if there aren't 4 (unless
there aren't any. ;-)
this are the little delights of spec interpretation ;)
although your proposal would be consistent with the behaviour of
insert i'll tend to prefer to take it's stated 9.3.6 The delete
Element.
Already under 1. you can read: "If the collection is empty, the
delete action has no effect."
and then under 2. (as you've stated): "If no nth node exists, the
operation has no effect."
this means for me that here an index bigger the size of the
nodeset must be meant cause 1. already 'ensures' the existence of
a nodeset.
anyway, not doing anything here is at least less destructive ;)
and the defensive way to implement it. if we learn something
different later we can change it - we have tests :)
Joern
Anyway, #1 is somewhat inconvenient, #2 just a nit.
Thanks, Paul
Paul Miniato Architect/Designer http://ecommerce.cucbc.com
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| |
