XML Form Builder Error Messages

[J. Nichol]

I've been submitting some test records to our Islandora instance via an Islandora form that is more complex than the out-of-the-box forms for various content models--and failing every time. We've been ingesting everything in batches up until now. The error messages I've been receiving at each unsuccessful attempt are too Delphic for me to get any sense of what might be wrong with the form ("The website encountered an unexpected error. Please try again later"). Nor are the under-the-hood error reports much more enlightening. The most recent one, for instance, describes the problem as a "recoverable fatal error"--something of a contradiction in terms, one would think-- and notes that "Argument 3 passed to Create::append() must be an instance of DOMElement, instance of DOMText given, called in ... on line 168 and defined in Create->append()(line 307", evidently a clue that an XPath expression at some unspecified place in the form is incorrect. I've been informed, alas, that the "168" and "307" in that statement do not identify lines in the exported XML form where I could find the error. Perhaps the error is of a cosmic variety, too pervasive to be limited to one or two places.

What would be extremely helpful in the XML Form Builder is some sort of mechanism that could at least identify the place/line in the form or in the XML export of it where problems are occurring. Without it, one can only pore over the form again and again in a vain search for the error(s), or hope that someone, somewhere might be kind enough to look over the form, a task that seems akin to scrubbing out several large grease-caked deep fryers for free. If anyone has any advice, it would be greatly appreciated.

Many thanks,

Joseph Nicholson

[Daniel Aitken]

I’ll chime in here while I’m waiting for some XSLTs to run their Ts

Sadly, thorough error reporting in XML Form Builder is something of a pipe dream. Even ignoring that making a fully accurate error-reporting Form Builder and API would be essentially as laborious and difficult as making a second XML Form Builder layered on top of the first one, there’s also the consideration that XML Form Builder doesn’t really have a way of knowing what you intended to do when you didn’t quite make it there, making a lot of error cases pretty much impossible to report.

That doesn’t really apply for the stuff like the ‘recoverable fatal error’, though, which just means that the error was bad enough that it halted execution, but not bad enough that with some concessions in the code you couldn’t keep on going. That’s not exactly something we want to do though in this case, since by this point the form is already in a bad enough state that we shouldn’t try to finish the whole thing. PHP doesn’t know that - hence the error.

The most help I can give you, probably, is that if you can’t get to the point where your form would load existing XML or write to XML, there’s three cases that cover almost every issue:

1. There’s invalid XPath somewhere
2. Drupal takes issue with your tree structure of elements
3. An element is being used in a way it’s not supposed to (e.g., weird XML writing or CRUD actions)

Your recoverable fatal error sounds like the third one, possibly because of the fourth bullet point listed below.

Invalid XPath will generally produce some friendlier errors; it’s the other two that are way more esoteric and require some digging to resolve.

Some stuff to look out for in your form that I noticed:

• Any element that isn’t the root form that uses ‘document’ as the path context: these should almost always be avoided, and use ‘parent’ as the context instead, to avoid conflicts. There are very few times when an element should be searched for from the document context. This is especially true of repeatable elements (i.e., ‘tabs/tabpanel’ and ‘tags/tag’), which should always have the parent context, otherwise you can guarantee it won’t read/write from/to the correct element. Consider changing places where you’re creating on the document context at the path /mods:mods to creating on the parent context at the path self::node(). Consider also removing the trailing / on read action paths and simply changing the context to parent.
• Elements that are children of tabs/tags elements that are not tabpanel or tag, respectively (i.e., typeOfResource is a textfield that is a child of the name tabs element).
• Tabpanel and tag elements that use Update actions instead of Delete actions. Repeatable elements should always delete/recreate themselves instead of updating themselves; otherwise, collisions will occur when XPath tries to read the given path and then update it.
• This particular encoded XML value for Conference Name’s create action: "&lt;name type="conference" /&gt;” … I have to imagine something somewhere in the chain isn’t happy about the escaped < and >. It also shows up in temporal/temporalBegin and temporalEnd
• Invalid XPath (I notice mods:subject:temporal[@point='start’] instead of mods:subject/mods:temporal[@point=’start’] for the temporal tag.). This catches up literally everyone. If someone tells you that every form they’ve ever written has perfect XPath on the first run, that person is a liar.
• Rogue read actions on tabs elements (I notice on identifier, accessCondition). These can be dropped. I’m not sure what effect they’d have on the form, but typically tabs and tags elements require no CRUD actions.

There’s something of a document detailing the basics of XML Form Builder/API weirdness at https://github.com/Islandora/islandora/wiki/Creating-and-Working-With-XML-Forms … it’s by no means complete, but the Drupal form element reference chart section contains some typical CRUD setups and notes for element types, and the Common Scenarios section gets updated occasionally with some things that occasionally trip me up.

- QA Dan

On Jun 24, 2015, at 9:26 AM, J. Nichol <jnic...@uncc.edu> wrote:

The form in question is attached.

Regards,

Joseph Nicholson

--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
Visit this group at http://groups.google.com/group/islandora.
For more options, visit https://groups.google.com/d/optout.
<Audio Experiment 2.xml>

[J. Nichol]

Mr. Aitken,

It was extraordinarily generous of you to take the time to look at the form and offer these useful pointers and links. I'll carefully study the form with what you've said in mind. Thanks very much indeed for your willingness to help.

Joseph