Forms Service

The Forms service enables you to create interactive data capture client applications that validate, process, transform, and deliver forms typically created in Designer. Form authors develop a single form design that the Forms service renders as PDF, HTML, or as Guides (deprecated) in a variety of browser environments that support Adobe Flash Player.

Important: Effective March 10, 2012, Adobe is deprecating the Guides capabilities of Adobe® LiveCycle® ES. The Guides functionality is available for upgrade purposes only and will be removed from the product after two major releases.

The Forms service renders interactive PDF forms. An interactive form contains one or more fields for collecting information interactively from a user. An interactive form design produces a form that can be filled online or (in the case of PDF forms) offline. Users can open the form in Acrobat, Adobe Reader, or an HTML browser and enter information into the form’s fields. An interactive form can include buttons or commands for common tasks, such as saving data to a file or printing. It can also include drop-down lists, calculations, and validations.

When an end user requests a form, a client application such as a Java servlet sends the request to the Forms service. The Forms service returns the form in an appropriate format to the end user. When the Forms service receives a request for a form, it uses a set of transformations to merge data with a form design. It then delivers the form in a format that best matches the presentation and form-filling capabilities of the target browser. For example, if the end user requests a PDF form, the Forms service renders an interactive PDF form.

The Forms service performs the following functions:

  • Provides server-side execution of the intelligence that is in the form design. The Forms service executes the validations and calculations included in the form design and returns the resultant data to the browser.

  • Detects whether form design scripts should run on the client or the server. For clients that support client-side scripting such as Internet Explorer 5.0 and later, an appropriate scripting model is loaded into the device so that the scripts can run directly on the client computer. For information about the properties and methods supported in each transformation, see the Transformation Reference.

  • Dynamically generates PDF, SWF, or HTML content based the user's preference for a specific form design with or without data. An HTML form can deliver multipage forms page by page. However, a PDF form delivers all the pages at once. In Designer, the form author can script the current page number in the form design. The Forms service can merge one page of data that is submitted at a time or merge only the single page into the form design.

  • Supports subforms created in Designer. The Forms service adds extra fields and boilerplate as a result of merging the form design with data or as a result of scripting. With HTML, the added subforms can grow to unlimited page lengths. With PDF, the added subforms paginate at the page lengths that are specified in the form design.

  • Renders forms based on fragments. Fragments allow you to share form and script objects that are external to form designs. You can design parts of a form once and reuse them when designing collections of related forms. When creating a new form for the collection, you simply insert a reference to the fragment. When a form author updates a fragment, all forms that contain a reference to the fragment reflect the changes (when the form is rerendered).

  • Validates data entry by performing calculations, accessing databases, or enforcing business rules on field-level data.

  • Renders forms with file attachments. Also, the Forms service can process form submissions that contain file attachments.

  • Displays validation errors in different ways (split frame left, top, right, bottom; no frame left, top, right, bottom; or no UI). This is all done without maintaining any state on the server. The validation errors are also made available in the XML-based validation error document.

  • Maintains the state of any pass-through data that the application passed in. Pass-through data is data that does not have corresponding fields in the form design being processed. The pass-through data is passed back to the calling application after the target device submits the data.

  • Enables a non-technical user to amend a form design by using Designer to meet ongoing business requirements. In contrast, a web application that displays HTML pages may require a user to modify HTML or XML source code to make changes to a web page.

    For information about initially setting up this service, see Configuring LiveCycle Forms in LiveCycle Administration Console Help.

// Ethnio survey code removed