|
Behavioral differences exist between form designs that
are used to render PDF and HTML. Form designs rendered as PDF are
viewed using Acrobat or Adobe Reader.
If you are rendering a form as HTML, some client devices (for
example, older browsers) do not provide the same support level for
individual object properties. To create a single form design that
reduces these limitations, follow this process:
To determine how objects behave in a particular client
device, see the Transformation Reference.
If you are designing a form with a fixed layout and want
to output the form as HTML, enable transformation caching. (See Designer Help.)
When creating a form design, try to work around limitations
by finding ways to implement the form without relying on unsupported
object properties.
If required, include a layout that works for both PDF and
HTML.
Read "Creating Accessible Forms" in Designer Help and use the guidelines
to build accessibility into your form design.
Ask your form developer where scripts should run. By default,
scripts run on the client. If the scripts you include in a form
design must run on the server, or both the client and server, you
may have to change the default setting. For example, a form design
may contain a script that extracts data from an enterprise database
that is available only on the server. In this situation, the default setting
must be modified so that the script runs at the server.
Periodically preview the form by using Designer or the client
device (for example, a web browser) to troubleshoot problems early
in the design process.
If the Forms service will be prepopulating forms with data,
use test data to thoroughly test your form design.
For the
Forms service to retrieve form data, perform calculations, or validate field
data, the form must provide the mechanism to initiate the request.
This is typically accomplished through the use of buttons located
on the form design. The caption that is displayed on a command button
label indicates the function of the button to the end user. When
a user clicks a button, the form-related processing is prompted
by the script that is associated with the button. Typically, a button
initiates either a submit operation or a calculate operation.
Buttons
are the most common way to initiate logic that is contained in form design
scripts. Placing a button on a form design in Designer and configuring its
submit option implies a submit operation. The intent of a submit
button is to complete the form and submit data to the Forms service.
However, validation operations may interrupt this process. For example,
if a user enters an incorrect value, the user may have to correct
the value before the form data can be submitted. Placing other button
types on the form implies a calculate operation. The intent of a
calculate operation is to run calculations and update the form before
a submit operation.
|
|
|
