Bug #1502
Quirky behaviour on wrong XML
| Status: | Resolved | Start date: | 2015-12-18 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Nicholas Jillings | % Done: | 0% | |
| Category: | - | |||
| Target version: | - |
Description
By accident my pre-test survey had <checkbox></radio> in it, and it skipped right to 'Thank you' (i.e. the end of the test).
See attached 'error' XML file that was saved.
I would say that at the very least, the subject/user should be informed of something having gone wrong - otherwise it could take a while before someone notices part of the test was not done by a number of subjects. Even better if the info that is stored in the XML (which says 'closing tag mismatch') is displayed there.
Of course, the test-create tool etc should be able to check XML for errors as well.
test-14.xml 
1.87 KB, downloaded 18 times
History
#1
Updated by Nicholas Jillings almost 9 years ago
The problem is the actual parser will fail because the XML is invalid and therefore no node will exist for this. If you check the results XML you see it gives you the error and says "on line 13 at column 12: Opening and ending tag mismatch: checkbox line 0 and radio.
It is a big item to add in (and will be in) but will take a long time to get it implemented and to work out what errors are fatal, recoverable or should be fatal. This is the risk of editing an XML file directly, even dropping the file into the test creator tool for verification would stumble on the same error
#2
Updated by Brecht De Man almost 9 years ago
Yup, saw that in the XML. I'm just worried because no error message is shown in the browser, so it may go by unnoticed and result in skipping parts of the test.
I appreciate it's complex to address though. If you think even a very broad error or warning message can be added, then I think this is worth doing, while anything more specialised isn't very urgent at all.
If it's not, feel free to move this down the list of priorities, especially if test_create would allow XML checking?
#3
Updated by Nicholas Jillings almost 9 years ago
The issue is the XML parser doesn't spit back an error, it just returns what it could parse and sends that on to the Specification node which will actually work on the node. I may try and see if the parser errors are consistent since then a quick detection for that error node would work and we can show an error from that.
#4
Updated by Nicholas Jillings almost 9 years ago
The browser will now show, on page, the parser error it encountered.
#5
Updated by Nicholas Jillings almost 9 years ago
- Status changed from New to Resolved