Adobe xml form object model reference

Class hierarchy Parent class Current class Objects derived from this class node class content. Class hierarchy Parent class Current class Objects derived from this class node class model. Properties Name Description Type Access aliasNode Specifies the object that is represented by the alias for this model. Empty createNode Creates a new node based on a valid class name. Object isCompatibleNS Determines if a specified namespace is functionally equivalent, that is compatible, with the namespace of this model.

Class hierarchy Parent class Current class Objects derived from this class node class textNode. Class hierarchy Parent class Current class Objects derived from this class None.

Determines the name of the class of this object. Specifies the number of objects in the list. Inserts a node before a specific node in the node list. Describes a zero-based index into the collection. Gets the first child of this node with the given name. Returns a collection of like-named, in-scope nodes. Returns a collection of like-class, in-scope nodes. Returns the position of this object in its collection of like-class, in-scope objects. Returns the position of this node in its collection of like-named, in-scope nodes.

Specifies an identifier that may be used to specify this object or event in script expressions. Returns a list of all child objects of the current object. Returns the parent object of the current object.

Reads the reference syntax expression for this node. Specifies whether this object is a container object. Indicates whether the current data value is the null value. Specifies the model for the current object. Checks if a specific property has been defined for this node. Loads and appends a specified XML document to the current object.

Saves the current node to a string, but includes only a subset of the child nodes. Sets a specified object to be the current object. Gets a delta script object for a specific property. Specifies the object that is represented by the alias for this model.

Interactive form designs may have associated data that they are merged with, but most interactive forms are designed to support user-entered data. The process up to and including the creation of the form DOM is identical for all forms. However, non-interactive forms have a set of data to merge with their form design.

In the case of forms that have a fixed layout, data merging does not determine the presentation rules for the form; that is, data is merged into the appropriate fields without changing the field properties.

In contrast, when data is merged with forms that have a flowable layout, the fields grow or shrink to accommodate the amount of data merged into them.

The Form DOM for forms with both fixed and flowable layouts looks very similar; it is one long form with no pagination. When the data and presentation rules are applied to these types of forms, they must be formatted according to the layout information.

A Layout DOM is created from the Form DOM that structures the form into pages and applies any other page-based rules, such as page numbering, headers, and trailers.

The following diagram illustrates this process. After the layout rules are applied to forms that have a fixed or flowable layout, both types of forms are complete. The connectionSet model controls a data schema as well as a data source used by a particular form. The Data model is the in-memory representation of user data. When a form design and data are merged using the data-binding process, the data model supplies the content for fields on the final form.

The Event model controls the changes in a form that occur before, during, and after actions take place. These actions include dynamic form events, such as the point when the data and form design are merged but before any pagination is applied, as well as interactive form events such as when a user updates the value of a field. The Form model is the in-memory representation of the merged Template model and Data model.

Using this model, you can affect the look of the form, adjust field values, or perform other changes prior to either displaying the completed form to a user or processing the form through the Layout model. Scripts run against the Form model by default; therefore, you do not need to specify the Form model in your reference syntax.

The Host model provides a set of properties and methods for working at the application level. These properties and methods are available for scripting regardless of the hosting application.

The Layout model is the in-memory representation of a form after it is merged with data. This representation is the final layout of a form. The server does not implement these methods and instead can output an error message if a user tries to call the method. For information about the basics of creating scripts, see Scripting Basics.

In Designer, forms are documents that are created from a hierarchy of optionally repeating building-blocks known as subforms. Each subform controls a portion of the overall structure, presentation, and behavior of the form.

Individual subforms enclose a combination of objects that produce fillable regions fields and non-fillable regions draws.

Subforms may also contain other subforms, and each subform may have properties that determine how and when the subform is instantiated into a constructed form. Within each form is a concept of a container.