Stefan Cameron on Forms
Building intelligent forms using Adobe LiveCycle Designer

Careful with Form Compatibility Settings

Let me put it simply: I got burned by using a particular syntax to check the existence of a field inside a subform object due to form compatibility settings in LiveCycle Designer 8.2.

What?

It started with a form I had created using Designer 8.1 which was set to target Acrobat 8.1/XFA 2.6. Later-on, I installed Designer 8.2 and wanted to update my form to target Acrobat 9/XFA 2.8.

In my form, I had a script object with various functions that used the following syntax to test the existence of a field inside a subform object which was passed-in to these functions as a parameter:

if (subformObj.someField)

The result of this was what I expected: If ’someField’ existed inside ’subformObj’, the IF statement would evaluate to ‘true’; if it didn’t, it would evaluate to ‘false’. According to the rules of dynamic properties in JavaScript, this was all fine and dandy.

All my scripts were set to run on client only. Then I found myself having to execute them on the server. So I set all my scripts, including my script object, to Run At ‘Client and Server’ using the Script Editor. That’s when the problems first started showing-up. The server log showed the following error messages whenever the JavaScript engine would come across the above IF statements in cases where, after a little investigating, I determined ’someField’ was not inside ’subformObj’:

GeneralError: Operation failed.
XFAObject.someField:2935:XFA:form1[0]:bodyPage[0]:subformObj[0]:otherField[0]:initialize
Invalid property get operation; subform doesn't have property 'someField'

But why was I getting these error messages? My form was executing just fine in those circumstances on the client (in Acrobat and Reader 9) and I even had "Form Properties > Defaults > Enforce Strict Scoping Rules in JavaScript" enabled in my form.

Why?

Well it turns-out that while my form was now targetting Acrobat 9/XFA 2.8 (since my <template> node’s namespace, in the XML Source view, was properly set to "http://www.xfa.org/schema/xfa-template/2.8/"), it was still behaving like an XFA 2.6 form! That meant that my scripts were subject to the same rules as scripts running in Acrobat 8.1, not Acrobat 9.

Back in Acrobat 8.1/XFA 2.6, the client-side XFAObject form objects in JavaScript supported the addition of custom/dynamic properties yet the server-side (LiveCycle; xfa.host.name == "XFAPresentationAgent") ones did not. Hence the error messages like the one above.

How did this happen? Well, when I opened my old Designer 8.1 form in Designer 8.2 and updated its target to Acrobat/Reader 9 and XFA 2.8, Designer did what it does by default which is insert the following processing instruction in the form in order to give the form access to the new XFA 2.8 APIs yet make it still behave like an XFA 2.6 form in order to maintain compatibility:

<?originalXFAVersion http://www.xfa.org/schema/xfa-template/2.6/?>

Unfortunately, that’s not what I wanted. My intention, when updating the form’s target version, was to make that form Acrobat 9 + XFA 2.8 compliant — even if it meant I had to potentially deal with some behavioral differences — in order to take full advantage of all the new features and bug fixes.

Once I removed the offending processing instruction (by going to the XML Source view in Designer and removing it manually since there’s no UI to do this), Acrobat and Reader 9 began to throw the same exceptions as the server which was good because it meant I was finally in the situation I had wanted all along: XFA 2.8 compatibility and behavior!

Thankfully, fixing my script wasn’t too difficult. The new version,

if (subformObj.resolveNode("someField"))

works very predictably for both client- and server-side rendering and what’s more, the custom/dynamic properties I do create on regular JavaScript Object variables are safe from garbage collection.

Recommendations

If you want to understand more about form target and compatibility settings along with the do’s and don’ts of custom properties in JavaScript within XFA forms, I highly recommend you read John Brinkman’s posts on the scope of JavaScript objects and form compatibility settings.


Posted by Stefan Cameron on February 11th, 2009
Filed under Acrobat, Debugging, Designer, Scripting, XFA
You can skip to the end and leave a response. Pinging is currently not allowed.

Leave a Reply

Alternate Help: Unfortunately, I am not always able to keep track of older posts. Please feel free to continue discussions here or seek help at an Adobe Forum: Designer/Acrobat, Designer ES, Designer (v6-v8), XFA Forms, Acrobat, Reader.

If you're including scripts: To make sure your script and comment are properly interpreted, please make sure you replace any less-than ("<") characters with their character code equivalent: "&lt;" (without the quotes). Otherwise, your script and comment will inadvertently be cut short.