[Laszlo-dev] [Platform-team] testing
André Bargull
andre.bargull at udo.edu
Tue Dec 2 10:12:00 PST 2008
The change was initiated because of "Example 37.22. Datapath iteration
workaround" in
"http://labs.openlaszlo.org/trunk-nightly/docs/developers/databinding.html#d0e98637".
(note: the text doesn't match anymore the code, this needs to changed)
If you moved to the last entry ("Mary Brown") and then hit "Delete
record", nothing was displayed anymore. This happened because the
previous sibling wasn't selected. But if you, let's say moved only
forward to the third entry, and then "Delete Record", you'd see another
entry (the ex-fourth entry). The example told you to reset the xpath
after calling "selectPrev()" resp. "selectNext()", but actually this
doesn't help you in this case. Instead you need to insert more logic
when you delete the node:
---
if has next-sibling then select next-sibling
else if has previous-sibling then select previous-sibling
else select nothing
---
And exactly this was added to "LzDatapointer#deleteNode()".
To answer myself:
> [...] maybe there is some reason not to select the previous sibling.
The next sibling is only selected if you set rerunxpath to `false` (it
is set to `true` by default for datapaths). If you don't select the
previous sibling, you'd get similar behaviour to datapaths with
rerunxpath="true", BUT as soon as the xpath is a bit more complicated
(e.g. by predicates), this logic breaks..
---
<dataset name="ds" ><apple /><cherry /><dataset/>
<view id="foo" ><datapath xpath="ds:/*[1]" /></view>
foo.datapath.deleteNode() -> foo selects "cherry"
<view id="bar" ><datapath xpath="ds:/*[1]" rerunxpath="false" /></view>
bar.datapath.deleteNode() -> bar selects "cherry"
<view id="foo" ><datapath xpath="ds:/*[2]" /></view>
foo.datapath.deleteNode() -> foo selects nothing
<view id="bar" ><datapath xpath="ds:/*[2]" rerunxpath="false" /></view>
bar.datapath.deleteNode() -> bar selects "apple" (was nothing)
---
On 12/2/2008 6:11 PM, Henry Minsky wrote:
> I would lean towards making it become null, because I like to have
> "less magic" when possible.
>
> But I don't feel too strongly about it in this case. David Temkin
> tended to like to have a little more "magic" in the language, to make
> it easier for people to put apps together faster with
> less code, but I find it easier when learning an API if the methods
> have simpler behaviors with less special cases, which are are easy to
> remember and describe.
>
>
> Keeping the old
> behavior would also be one less thing to worry about to make life
> easier for people porting their existing apps to 4.2.
>
>
>
> On Tue, Dec 2, 2008 at 11:26 AM, André Bargull <andre.bargull at udo.edu> wrote:
>> If you delete a node (call it "A") through "LzDatapointer#deleteNode()" and
>> if this node has got a next sibling (call it "B"), the datapointer will
>> delete "A" and then select "B".
>> But if "A" has no next sibling, but a previous sibling (call it "C"), the
>> changed method will select "C" instead, but before the pointer was set to
>> `null`.
>> I said it is more reasonable to select any possible sibling (next _and_
>> previous), but the testcases seem to require that _no_ previous sibling is
>> selected. Changing the testcases to match the new semantics is surely
>> possible, but maybe there is some reason not to select the previous sibling.
>> Any ideas?
>>
>>
>> Ok, here's a simple example which will work in trunk-nightly.
>>> <canvas debug="true" >
>>> <dataset name="ds" >
>>> <items>
>>> <item id="a" />
>>> <item id="b" />
>>> </items>
>>> <items>
>>> <item id="c" />
>>> <item id="d" />
>>> </items>
>>> </dataset>
>>>
>>> <handler name="oninit" >
>>> var dp1 = ds.getPointer();
>>> dp1.setXPath("/items[1]/item[1]");
>>> Debug.write("valid = %w", dp1.isValid());
>>> dp1.deleteNode();
>>> Debug.write("valid = %w, id='%s' (expect '%s')", dp1.isValid(),
>>> dp1.getNodeAttribute("id"), "b");
>>>
>>> var dp2 = ds.getPointer();
>>> dp2.setXPath("/items[2]/item[2]");
>>> Debug.write("valid = %w", dp2.isValid());
>>> dp2.deleteNode();
>>> // this will work in trunk-nightly, but not in earlier versions
>>>
>>> Debug.write("valid = %w, id='%s' (expect '%s')", dp2.isValid(),
>>> dp2.getNodeAttribute("id"), "c");
>>> </handler>
>>> </canvas>
>>
>>
>>
>> On 12/2/2008 5:10 PM, Henry Minsky wrote:
>>> Oh sorry, I should have sent this to laszlo-dev....
>>>
>>>
>>> On Tue, Dec 2, 2008 at 11:07 AM, André Bargull <andre.bargull at udo.edu>
>>> wrote:
>>>> [I've removed the cc for "Platform Team
>>>> <platform-team at laszlosystems.com>"
>>>> because I haven't got access to that mailing-list]
>>>>
>>>> I'll track it down and check the assertions in the test..
>>>>
>>>>
>>>> On 12/2/2008 5:02 PM, André Bargull wrote:
>>>>> Ah, ok. The last change from Josh to "LzDatapointer#deleteNode()" is the
>>>>> culprit. So actually my fault, since I've proposed that change and
>>>>> approved
>>>>> the change, too...
>>>>>
>>>>>
>>>>> On 12/2/2008 4:41 PM, Henry Minsky wrote:
>>>>>> No, actually I did a clean build in a clean top-of-tree trunk and I
>>>>>> still get those errors. Looks like a real regression
>>>>>> from something. I think I will try max's binary search tool to find
>>>>>> which revision this happened in.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 2, 2008 at 10:35 AM, Henry Minsky
>>>>>> <hminsky at laszlosystems.com>
>>>>>> wrote:
>>>>>>> Actually, it looks like it's that changeset I just sent out for the
>>>>>>> datapath sortorder is causing a failure, it seems like it's only
>>>>>>> happening in my workspace that has that modification.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 2, 2008 at 10:23 AM, André Bargull <andre.bargull at udo.edu>
>>>>>>> wrote:
>>>>>>>> That's the cachebreak-test, you need to run alldata another time,
>>>>>>>> then
>>>>>>>> it
>>>>>>>> should work.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/2/2008 4:12 PM, Henry Minsky wrote:
>>>>>>>>> speaking of which , I am seeing these errors in alldata.lzx
>>>>>>>>>
>>>>>>>>> Tests: 325 Failures: 3 Errors: 0
>>>>>>>>> TestFailure: test2 failed: False: expected false got true
>>>>>>>>> TestFailure: test2 failed: False: expected false got true
>>>>>>>>> TestFailure: test failed: False: expected false got true
>>>>>>>>>
>>>>>>>>> I'm tracking down which test it is now. I guess we ought to be
>>>>>>>>> printing out the name of
>>>>>>>>> the test suite class that is running to make clear which test suite
>>>>>>>>> is
>>>>>>>>> failing.
>>>>>>>>>
>>>>>>> --
>>>>>>> Henry Minsky
>>>>>>> Software Architect
>>>>>>> hminsky at laszlosystems.com
>>>>>>>
>>>>>>
>>>
>>>
>>
>
>
>
More information about the Laszlo-dev
mailing list