Creating Variables in Script

The first parameter to createNode() can be any of the XFA content types. The set that you would likely find useful in a scripting context are: <boolean>, <decimal>, <float>, <integer>, <text>. You can create other types such as <date>, but a <date> behaves like a <text> (a string) because there is no date data type in JavaScript.

Typed variables

The .value property on a variable is a variant. It returns a typed value based on the content type. It will return string for <text> , it will return number for <integer>,<decimal> and <float> and returns boolean for <boolean>

Typed variables have the advantage that script operations that use them will do the right thing. e.g. if you define two <text> variables: v1.value="3"; v2.value="5", then the expression "v1.value + v2.value" will return "35". If they are defined as <integer>, the result of the expression is "8".

Use any Subform

The <variables> element may appear under any subform. It often makes sense to create the variable in the context where it is used e.g. in the case where it is used within a repeating subform or a fragment.

Hidden from the Designer

When you define script objects that use variables, it can be inconvenient to create the form variables from the Designer UI. If you do, your script then has an external dependency, and other people modifying the form can muck with your variables. It really only makes sense to create them from Designer if they truly have global scope. Of course, defining them in Designer does have the advantage that they show up in object assist.

Form State

Anatole Matveief wrote a nice form state tutorial on Stefan Cameron’s blog. As of Acrobat 9, form variables are stored as part of the preserved form state i.e. after save/close/open, any form variables will be restored. This can be a very valuable feature, but can also require some caution — when creating a new variable, you should first check for its existence. If not, you may end up with multiple copies of the variable. The existence check looks like:

Dependency Tracking

Unfortunately, variables do no participate in dependency tracking. If you define a calculation that uses a variable, the calculation will not re-fire automatically when the value of the variable changes.

What about Fields?

It is really convenient to be able to define variables in the context of a subform, but what about the case where your context is a field? The good news is that there are two places where we can place content elements within a field: <desc> and <extras>. For example, to create content under a field you can code:

6 Responses to Form Variables

If one just needs to store temporary information, related to a field or form, or whatever xfa object, one can create an “expando” property on it.There you can store all JavaScript possible types:xfa.form.MyField.__CACHE__ = {A: 123,B: “123”,C: new RegExp(“123”)};Of course, it all only exists as long as the related document.

Hi John,I’ve been using xfa.form.createNode and extras.nodes.append to create object holders for various properties which I want to persist for objects on my form.This has been working well through the development cycle, but as we prepare for rollout and test – it turns out that by creating nodes within JavaScript, it seems to invalidate the Reader Extension usage rights and if I save and re-open the form, I get the infamous message “This document enabled extended features in Adobe Reader. The document has been changed since it was created and use of extended features is no longer available.”Have you found a way to maintain usage rights while persisting dynamically created object properties?thanks- Duane

Thanks a bunch for the sample John.It appears to be an issue with Reader 8. When a property has been set to a value which was defined in a node (like an extras node) which no longer exists after a file->save … it invalidates teh usage rights.Cheers- Duane