There are a number of different ways to submit a form, and which one is right depends on context. When your form is part of a workflow created with Adobe’s Workflow Server, you need to submit using the LiveCycle Workflow fields:
These ensure that the user has the controls they need for the state they’re at in the workflow.
Outside of Workflow, you can still create forms that integrate with server side processes. Form Designer and Reader support two methods for submitting data: submitting form data as application/x-www-form-urlencoded using HTTP POST, and SOAP. The former is what I’m talking about in this post.
When you create an HTML form, you add some HTML fields, and a URL to POST to as the <form> tag’s action. For example:
<form method="post" action="http://stevex.net/dump.php">
<label>TextField1
<input type="text" name="TextField1" />
</label>
</form>
I’ve created a simple PHP script that dumps out what you submit to it parsed (so you can see what variables PHP found in the submitted data) as well as the raw POST body. The script is here. Typing "hello" into the text field and submitting this form shows that the following data was sent to the action URL:
TextField1=hello
Simple enough. It gets more complicated when there are more fields or special characters need escaping; the exact details of how that works are spelled out in the HTML 4.01 spec section 17.13.4 which covers application/x-www-form-urlencoded encoding, the MIME type that form data is submitted with.
So that’s how HTML submit works. What happens when you create a form with Form Designer and want to submit it using HTTP?
Here’s how to create a form equivalent to that little HTML form described above.
- Create a new form.
- Add some fields.
- Drop an HTTP Submit Button from the Library.
- Configure the HTTP Submit Button.
After step 3, you’ll have a Submit button on the form, with a wee yellow marker. Hover the mouse over the marker and you’ll see this message:
This handy reminder just lets you know that you need to click on the Submit button and in the Object Inspector, set the URL that the form will be posted to to something. (I don’t know about you but when creating HTML forms I’ve forgotten to enter the action URL more than once).
Designer’s preview is actually an embedded Internet Exporer, with a temporary PDF rendering of your form loaded into it. This means clicking the Submit button in the preview window will submit your form and you can see the results of the submit right in Designer.
Submitting from Acrobat is a bit more involved because Acrobat can’t display the HTML response directoy, but what happens is actually pretty cool. The HTTP submit happens, and the resulting HTML is captured by Acrobat and converted into a PDF, so you see the dump response page, but you see it in Acrobat as a PDF.
There are some limitations that come with submitting form data as HTTP. Because HTML forms aren’t hierarchial, any hierarchy in your own form is lost – for example, nesting fields within subforms will cause them to not appear in the submitted data. These limitations are mentioned in Designer’s documentation.
I’ve attached my sample HTTP Submit PDF form
so you can have a look at a few different field types and how they look in the submitted data.
So that covers HTTP submit. You can do a lot more with SOAP than just submit data, but that’s another story.
