You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Ubiquity XForms Contributors
I'm looking for some suggestions on the following issue:
-Currently the waitForModel ready is used to "waitForModelReady" but
when used with exceptions the model may never become ready and
therefore fail hence the script failure.
-The waitForModelReady user extension seems to exploit a boolean value
that is set by the XForms processor when the model is ready.
- I had some ideas on how to implement this automatically without
using the waitForModelReady and without using a pause (which some
scripts seem to use to get around this).
1. I could either set a boolean flag saying an exception had been
dispatched. I'm not a fan of adding a boolean flag to all exceptions
but I think it would get the job done. Then we can just wait for a
true evaluation and check the exception. This may create a condition
where the script would fail if there where multiple exceptions on the
form.
2. We could axe the other checks in the form, just load it and wait
for the *xforms-binding-exception* or other exception.
Suggestions?
Thanks,
Erik
John Boyer
unread,
Oct 8, 2009, 7:57:50 PM10/8/09
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to ubiquity-...@googlegroups.com, Ubiquity XForms Contributors
Hi Erik,
Your ideas here reminded me to mention
that the "FormsProcessor" object already contains a boolean called
'halted' that is initialized to false but is set to true when there is
an exception.
The overachieve would be to set up a
listener for the exception event. This could be done via an extension
because the exceptions don't simply happen, but they also have a detectable
event. However, it is a reasonable cross between prudence and expedience
to simply test for halted=true because the issue of multiple exceptions
doesn't really get in the way for the test forms (agreed it would be an
issue in practice, but these are point feature tests). Also, it is
more important overall to test that the processor halted than it is to
test that the exception occurred anyway.
As an aside, not sure why I can't find
waitForModelReady definition when I do a full text search of the entire
project for all files matching *.*. I just want to read the implementation
of waitForModelReady, so could you point out which file it's in please?
Thanks,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boy...@ca.ibm.com
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to ubiquity-...@googlegroups.com
Hi John,
Good idea I will set-up the check for that. As for the waitForModelReady. It's listed under isModelReady added to the Selenium prototype object in user-extensions.js in the selenium core. Selenium then allows the test to issue a waitFor command as a prefix.