It's not a tutorial so much as it is a quick tour, but if you're curious about LiveCycle, Designer, Workbench and how they interact, have a look.

Quite a few people have commented on an entry I posted back over a year ago, where I talk about the data format that's POSTed from a form to an HTTP server.  The data format is supposed to look something like this:

TextField1=test1&TextField2=test2&RichTextField=&ListBox1=&RadioButtonList=

However, some of you said that you were getting data that looked like this:

TextField1=test1TextField2=test2RichTextField=ListBox1=RadioButtonList=

This was actually a bug in Acrobat 8.0, and is fixed in the 8.1 update. If you're running Acrobat 8.0, allow the Adobe Updater to install Acrobat 8.1 and you'll get the data in the correct format.

There's a lot to talk about with version 8.  One of the big new features is a new type of form designed for users who need to take an existing form (either scanned or generated in some other program) and make it an interactive, fillable form while preserving the exact look of the original form.  Just what you'd expect from PDF.  We'll be talking about this more once more infomation on the product has been released.

On a related note, it's great to see Breeze getting the spotlight through it's rebranding as Acrobat Connect.  Breeze is the best collaboration tool I've used.

Last year's MAX experience for me was mostly about discovering that the Flash player has become a serious virtual machine and runtime for even CPU-intensive applications, thanks to its ability to compile ActionScript down to native code.  There's even a Commodore 64 emulator for Flash Player 9. 

And it was about discovering Flex and Flex Builder, the Eclipse-based IDE that you use to build Flex apps.  I had no experience with Flex before MAX; now it's near the top of my "things to dive into more deeply" list.

Last year, MAX happened just before the Adobe / Macromedia merger was finalized, so there wasn't any official Adobe sessions; this year, MAX has a track for Adobe LiveCycle Technologies.

This year Flash and Flex folks will have the opportunity to discover LiveCycle the way we LiveCycle folks had the opportunity last year to discover Flash and Flex.

If you're in that boat, don't miss Matt Butler's session on Adobe's Core LiveCycle Architecture and Hands On Deployment, and Sanga Viswanathan's session, LiveCycle 8: What's Coming. 

I was reminded of this just recently, when I was filling out the Tarion 30 day warranty form for my new house.

I received a paper copy of this form as part of the huge stack of documents I got when the house sale closed, but after compiling a list of ~30 items, I just didn't feel like writing it all out. That's where Acrobat comes in.

Fillable forms come in two flavours: XFA and Acroform. Acroform forms are forms where you've placed the input fields on the form using Acrobat itself; XFA forms are forms created using the Form Designer tool.

I found the forms online, but they're not fillable. This is pretty common - form authors create forms using something like Illustrator or InDesign, and then create a PDF from that and just post it online, rather than taking the extra step of importing that into Form Designer and adding fields.

But Acrobat has a feature that's designed for this specific problem: The Typewriter Tool.

I loaded up the Tarion form, got out my handy typewriter, and filled out the form. Printed it, signed it, and faxed it off.

The nice thing about doing it this way is that as I was filling out the form, quite a few times I had to go back and edit something; if I was filling it out on paper, that would have been impossible. I could have filled out a draft on paper and then copied it to the real form, but that's just more work.

What would the next best thing have been? Loading a bitmap of the form into PhotoShop and filling it out there, I guess - doable, but not nearly as easy.

It can seem like we have two products competing for the same sort of market, in that we have Form Designer and PDF forms, and then we have Flex Builder and RIA's. But these are really two different things, and serve different purposes.

It comes down to the difference between a "Dynamic Document" and a "Rich Internet Appplication".

With Flex, the focus is on the application. The application loads, and then maybe fetches some data, or maybe lets you create some data; but what matters is the application.

With PDF Forms, the document is the focus. You can sign the document, encrypt it, run validations on the data it contains, and so on, but it all revolves around the document.

You wouldn't build a shopping cart with Form Designer, but you wouldn't create an invoice with Flex. Each tool has its place.

There's going to be some real power around the combination of these two.

PHP Submit Sample

This sample has a couple of text fields which, when submitted using either of the buttons on the form, echoes the text back to you by the PHP code on the server. The server code is also included in the form.

I've created a Submit Comparison PDF that has a few fields on it, and buttons for the four different types of data submission that Acrobat supports.

These are: XDP, PDF, XML, and URL-encoded.

URL-encoded is what the HTTP Submit Button does; to use one of the other formats, drop a Button onto your form, set the Control Type to Submit, and then you can use the Submit tab on the Object Inspector to control how the data is submitted.

Submitting in XDP format gives you XML data that includes an xfa:data model, as well as an execEvent node that identifies which button the user pushed to submit the form. This provides the most data.

Submitting XML gives you the same data that you'd get if you emailed the filled out form data from Reader - it's an XML packet with a chunk of friendly human-readable text that describes how to submit the data. The form data you get is the same as what you get with the XDP format, but without the xfa wrappers.

Try out the PDF file I linked above - the Submit button posts to my dump.php script so you can see what actually got submitted.

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.

1. Create a new form.
2. Add some fields.
3. Drop an HTTP Submit Button from the Library.
4. 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.

If you haven't got a Form Designer to install, you can find a free Tryout version over here.

All I wanted to mention today is one tip regarding scripting.

Often I fire up Designer to try something out, and today I was having trouble. I added a button to my form, added a text field, and added some script that would run when the button was clicked. But when I previewed the form and clicked the button, nothing happened.

When I saved the form as an XDP file, however, and then previewed and clicked the button, it worked fine.

This was a new computer I was trying this on, and I'd forgotten an important setting. In the Options dialog, the first option on the first page of options is "Default file type for new forms".

If this is set to the default of "Static PDF Form File", then your scripts won't run. If you plan to be doing any scripting in Designer, then set this to "Dynamic PDF Form File".

The XFA forms that Designer creates don't work in old versions of Acrobat Reader, which is why this option is off by default. But if you're developing interactive forms, you'll probably want your users using a recent version of Reader, and having this option set to static forms by default means whenever you create a new form, none of the scripts you're writing will work until you actually save it to disk as an XDP file or interactive form.

Designer comes with Acrobat Professional, although it's not installed by default. If you have Acrobat installed, and you don't have Designer, go dig out your Acrobat disc and install it. I'll wait here.

So here's mine. Hi!

Difference is, of course, that I'll be back.

(But that's what they all say isn't it? Stay tuned...)