Part VIII of this book is related to working with XML forms—particularly dynamic XML forms. We use the term dynamic throughout the second half of this book to refer to a certain type of form created in LiveCycle Designer that has what Adobe refers to as dynamic elements.
In Chapter 23, we talked about designing forms in LiveCycle Designer—both static and dynamic. In Chapters 24 and 25, we covered the essential tools, field and object properties, and commands that you need to become familiar with to create a form in Designer.
In Chapters 27 and 28, we talk about making forms dynamic using a number of methods you can employ in Designer to add dynamic characteristics to forms.
Before you embark on setting up a form containing dynamic elements, it is helpful to understand the differences between static forms and dynamic forms and when you need to plan for one type of form or another.
This chapter provides an initial exposure to the different form types and some introductory information you should know before moving on to the remaining chapters in this part.
Most of the forms we created in the chapters related to Adobe Acrobat are static forms. A static form contains a number of field objects that are fixed on the form and designed for user input as the form appears when opened in Acrobat. In some earlier chapters related to creating a form in Acrobat, we worked with forms similar to the one you see in Figure 26.1.
The form shown in Figure 26.1 is a static form. All the field objects on this form need to be planned ahead of time because the form recipient has no way to add field objects to the form. The ability to add field objects is one of the factors that make a form dynamic.
Note
To examine the form shown in Figure 26.1, look in the Chapter 26 folder on the book's CD-ROM and open the applicationDesignAcrobat.pdf file.
In Figure 26.2, you see a form created in LiveCycle Designer that is very similar to the form shown in Figure 26.1. However, on this form, notice the text where you see Add Reference and Remove this Reference. These objects are buttons that either add a new line to the table where the References section appears on the form or removes references from the form.
Note
To examine the form shown in Figure 26.2, look in the Chapter 26 folder on the book's CD-ROM and open the GFApplication.pdf file.
The form we created in Acrobat to demonstrate the comparison between static forms and dynamic forms is a single-page form. The form we created in LiveCycle Designer is a two-page form. When you open the second page of the form, you see more buttons that are designed to add and/or delete additional elements, as shown in Figure 26.3.
The button on page 2 where you see Add Another Employer is designed, as you might suspect, for adding fields for the form recipient to detail a work history. As a form filler clicks the button in either Acrobat or Adobe Reader, additional field objects are added to the form. Figure 26.4 shows the form after we clicked the Add Another Employer button several times.
Figure 26.4. After clicking the Add Another Employer button on the form, the form's dynamic components permitted adding new field objects.
Acrobat forms are not typically referred to as being dynamic forms. A PDF form created in Acrobat does not support tools and structures needed to create forms similar to the dynamic forms we create with Designer. However, you can add some dynamic elements to forms created in Acrobat.
The downside for creating Acrobat forms with dynamic elements is that many of the forms won't work in Adobe Reader. An Acrobat form that supports adding new elements or data is not something a user can use with the Adobe Reader software. Designer forms, however, can be constructed so new objects and data can be introduced into a form at runtime using the Adobe Reader software.
Note
For more information on runtime, see the section "Understanding Runtime" later in this chapter.
In Chapter 19, we created forms that were designed for Acrobat users only. On a form like the Attorney Worksheet we used in Chapter 19 and which is shown again here in Figure 26.5, we have several dynamic elements at work.
A button on this form spawns a new page from a template. This action is a dynamic action that adds new pages according to the form filler's needs. Interestingly, spawning pages from templates is not supported in LiveCycle Designer. Designer, however, has its own method for creating new pages based on user demand or data flow.
The form shown in Figure 26.5 also has a button to send data from the form to another form where, through the use of JavaScript calculations, the data are summarized.
Note
To experiment with some dynamic features added to Acrobat forms, open the globalAttorneySpawnRaw.pdf file from the Chapter19 folder on the book's CD-ROM.
Using objects in Acrobat such as the docTemplate object and the addField object, you can add dynamic instances to PDF forms. However, you need to keep in mind that these dynamic features are supported only in Acrobat.
Note
For more information about using the docTemplate and addField objects in Acrobat, see Chapter 19.
In Chapters 27 and 28, we provide several examples and a thorough understanding for creating dynamic forms in Designer. We won't go into the hows for creating dynamic forms in this chapter, but we want to introduce the concept so it will be a little clearer when you start creating dynamic forms in the chapters ahead.
Dynamic instances with forms occur under two basic conditions. One condition is related to data flow. When data are imported into a form, you can have the data flow create the necessary number of field objects and pages required to display all the data. If, for example, you have one data file containing 10 records, the rows of field objects are created to hold all 10 records. If you use the same form and import another data file containing 100 records of data, the rows of field objects are again created to hold all the data. This may require additional pages that are dynamically added to a form to accommodate all the data.
The other condition where dynamic elements are added to forms created in Designer is having new objects added to a form based on user control. You can add buttons to Designer forms that add data fields when a form filler needs to add rows (or columns) of data.
When you introduce data in an XML form, you are working with a file that has data binding to a data source, and the field objects are defined with various types of data binding. Designer needs to know where to place data on a form when you import data and when you want data to flow in a form.
In Acrobat, we need to be certain that the field names in a data file match exactly the field names in a form in order to import data. When introducing data in a LiveCycle Designer form, we have many more circumstances to control. We need to choose the type of binding, what kinds of expressions to use, and what kinds of files we are binding to. As you move through Chapters 27, 28, and 31, realize that you need to work with data connections and binding data to field objects.
The dynamic features of some forms are apparent only when we use a form at what we call runtime. Runtime is related to either the use of the form by a form filler or when data are introduced in the form.
When data are imported, you see the dynamic features of a form realized, such as flowing data and populating the form with additional field objects. When a user clicks a button to add a new instance, it's a runtime event.
Changes that occur during the rendering process, or after the form has been rendered, are considered runtime changes and are not apparent at design time. To contrast the term, a Design Time change is any alteration made to the form while working in Design View or Master Page View of Designer.
As we explain in Chapter 28, dynamic forms are made dynamic through the use of subforms. For now, don't be concerned about creating subforms; we cover that in much detail in Chapter 28. What you want to be aware of at this point is that subform elements, as well as all the objects on a form, appear in the Hierarchy palette, as shown in Figure 26.6.
As you work with any type of form in Designer, and particularly forms with several subforms like the form shown in Figure 26.6, you'll want to locate and select objects and subforms in the Hierarchy palette. Poking around a form to select the right object where you want to change properties is much more difficult than clicking subforms and objects in the Hierarchy palette.
Dynamic properties are properties assigned to form objects from a data source and updated at runtime. For example, we used the form shown in Figure 26.7 back in Chapter 18 when describing a JavaScript that adds data from one list box to another. The form is designed as a static form in Acrobat.
If we design a similar form using Designer and we populate the form from a data source, the dynamic properties of a drop-down list or list box object could be set to populate the field object at runtime. The dynamic properties of such a field object permit you to modify objects that are outside the original form design and rely on the data source to display the data.
Static forms need to have all form field objects placed on a form during the design stage.
Dynamic forms conform to the data added to a form. You can design forms where the form recipient adds new instances to populate the form with additional field objects or flow data into a form where field objects are dynamically created to accommodate the data.
Some dynamic features can be added to Acrobat forms; however, using the forms is most often restricted to Acrobat only users.
When importing data into a form, you must create data connections to field objects. These connections are referred to as data binding.
Runtime is the term used when a form filler completes a form or data are flowed into the form.
Dynamic features of forms are executed at runtime.
When editing forms, use the Hierarchy palette to select subforms and objects.
Dynamic properties of field objects are assigned from a data source file and updated at runtime.