|
A button can submit form data as XML, PDF, or URL-Encoded
(for HTML submissions) data to the Forms service. For example, assume
a user fills an interactive form and then clicks a submit button.
This action results in the form data being submitted to the Forms
service. A client application, such as a Java servlet that is created
by using the Forms Service API, can retrieve the data.
A PDF form can submit four types of data (XDP, XML, PDF, and
URL-encoded data). An HTML form submits only URL-encoded name-value
pairs. By default, when the submission format is PDF, the Forms
service captures the PDF data and returns it back out without performing
any calculations. You set the submit type in Designer.
The content type of submitted PDF data is application/pdf.
In contrast, the content type of submitted XML data is text/xml.
For XDP submissions, it is application/vnd.adobe.xdp+xml.
This table summarizes the interaction among a client device (such
as a web browser), a client application, and the Forms service when
a user clicks a button that initiates a submit operation.
User actions
|
Client application actions
|
Forms service actions
|
|---|
A user enters data into form fields and
clicks a submit button. This action initiates a submit operation.
Client
validations marked run on client are executed.
|
No action
|
No action
|
Browser performs an HTTP post to the target URL.
(This value is defined either in Designer or by the targetURL parameter
used during the rendition call to the Forms service).
|
No action
|
No action
|
No action
|
Creates a FormServiceClient object, invokes
the processFormSubmission method, and passes the HTTP request and
headers.
|
No action
|
No action
|
No action
|
The Forms service merges posted data back
into the form (if applicable).
|
No action
|
No action
|
Executes the field click event.
|
No action
|
No action
|
Executes the form-wide field calculate events.
|
No action
|
No action
|
Executes the form-wide page calculate events.
|
No action
|
No action
|
Executes the form-wide field validation events.
|
No action
|
No action
|
Executes the page validation events (which include validate, formatTest,
and nullTest).
|
No action
|
No action
|
Executes the Form’s Close event.
|
No action
|
No action
|
If this validation process fails, it indicates that
at least one error exists. The returned processing state value is Validate.
|
No action
|
Verifies that the Forms service returned
a processing state value of Validate. In this situation,
the result is returned to the client browser so that the user can
correct the mistake.
|
No action
|
For forms that are displayed as HTML, end users
see the form that contains the same data, calculations, and list
of errors to correct before resubmitting.
For Guides (deprecated),
end users see the form that contains the same data, calculations,
and list of errors to correct before resubmitting.
For forms
that are displayed as PDF, a user interface is not defined. Validation
errors can be retrieved by using the FormsResult object’s getValidationErrorsList method.
|
No action
|
No action
|
No action
|
No action
|
If the validation process succeeds, the
processing state value is set to Submit.
|
No action
|
Verifies that the Forms service returns
a processing state value of Submit.
Acknowledges
that all form processing is complete.
Additional processing
is application-specific. For example, a wizard-style application
can request the next form panel, do additional data investigations,
update the database, or initiate a new workflow process.
|
No action
|
The view is application-specific. For example, a
new form can be displayed.
|
No action
|
No action
|
|
|
|
