Re: Test 10.8.e needs work

Hi,

For our implementation of Smartsite XForms, we made a few assumptions to get 10.8.e.xhtml to work:
Firstly, the schema allows event attributes on the model element, so we assumed that this was correct. We interpreted this test to mean that the defaultAction for the custom-event was to be cancelled on the model element. This works for 10.8.f.xhtml as well.
Because a custom event doesn't really have a defaultAction, we assumed that any handler for the given event is to be cancelled on the current element.
We've added our own tests for propagation="stop" which I would be glad to send you.


Met vriendelijke groet,



Douwe de Wilde

Senior Developer




[cid:image001.gif@01CCA061.6186AE30]





Elektronicaweg 31


2628 XG Delft, Nederland


T

+31 (0)15 - 251 37 00


F

+31 (0)15 - 251 37 01


E

dsdewilde@seneca.nl<mailto:dsdewilde@seneca.nl>


I

www.seneca.nl<http://www.seneca.nl/>







Op dit mailbericht is onze disclaimer<http://www.seneca.nl/disclaimer> van kracht.




----
Test  10.8.e purports to test the dispatch of a cancelled event.

The ev:event attribute was placed on the model element, not on the action
element that shows the message proving that the event was dispatched.  So,
the test requires that one should *not* see a message for the
custom-event, but the reason you don't see it is that the event attributes
are incorrect.

The ev:event attribute needs to be attached to the action element within
the model.

The model also has no instance, which is required, so I would not expect
this form to work.

However, we already have a test 10.8.d that tests dispatching a custom
event.  This test purports to test a cancelled event, i.e. one with a and
ev:defaultAction of cancel.  However, the test assumes that cancelling the
default action would cause the event bubble phase not to happen. The test
needs to use stopPropagation instead.  Then, another action handler needs
to be added to observe the parent of the event target instead.

So, I think this test should change by
1) adding an instance with an ID
2) targeting the custom event at the instance, not the model
3) attaching the ev:event and stopPropagation on the xforms action in the
model.

Then, we can claim that you shouldn't see the message.

Thanks,
John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com<mailto:boyerj@ca.ibm.com?Subject=Re%3A%20Test%2010.8.e%20needs%20work&In-Reply-To=%253COF4EA5C51B.4B06CE40-ON882576C0.005697D9-882576C0.00589318%40ca.ibm.com%253E&References=%253COF4EA5C51B.4B06CE40-ON882576C0.005697D9-882576C0.00589318%40ca.ibm.com%253E>

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw