Aggrey,

Based on what you wrote, I don’t think you need to worry about Flex just yet but here’s why you’re hearing/reading so much about it:

In Flash, you write in ActionScript. Flex is a framework written in ActionScript that provides thousands of utilities for building RIAs (in pure Flash, you have to create everything from scratch whereas with Flex, you get nice objects like buttons and drop down lists which you can extend to suit your needs).

With Flex, you can create much more engaging online experiences than you can with a regular XFA-PDF form. That’s why Adobe created the Form Guide technology which lets you create, using Guide Builder (provided with Designer 8.0+), Flex-based RIAs based on XFA forms.

Imagine how much easier and intuitive it would be to fill a complex, multi-page car insurance claim form if you had a Flex-based wizard built on-top of it that showed you a picture of a car with various hot spots that you could click-on and upload pictures of the damages (e.g. to the bumper, passenger door and rear bumper) instead of explaining, in words, what and where the damage is — and the form is filled for you in the background as you go through the wizard.

That’s what Flex-based Form Guide technology can do for you but you don’t have to know Flex in order to build Form Guides (unless you want to customize them to an extent not supported by Guide Builder).

Flex is blurring the lines that once existed between electronic forms and engaging applications you typically find online or on your desktop. With Acrobat 9, you can now add Flex apps into a PDF (since the Flash Player is now integrated into Acrobat) so you’ll start seeing much more engaging documents as well. With AIR, we’ve now shown that you can have an off-line Form Guide so the experience is even possible on the disconnected desktop.

Aggrey,

Unfortunately, there’s no email notification when I post a reply…

XFA is quite complex to learn on its own. What’s more is that it’s not really a language that you would benefit from learning to write by hand (though that may come with time and practice). You’re much better off downloading a trial of Acrobat Pro v9.0 which comes with a trial of LiveCycle Designer ES v8.2

Designer is the tool you use for designing XFA forms. You can then save them in PDF format from Designer and have recipients fill them using Acrobat/Reader.

The “Designing Forms” section of the LiveCycle Developer Center has lots of great resources though the most useful for you will be the LiveCycle ES Scripting Reference v8.2. If you’re up for it, you can also check-out the XFA specification v2.8 but Designer’s job is to do that for you.

Aggrey,

You’re welcome. I’m glad to help-out.

With respect to JavaScript, there’s “basic” JavaScript which is the language itself. That is, for the most part, common on anything that uses JavaScript as the scripting language (e.g. the fact that you concatenate strings using the “+” operator, you end commands with a semi-colon “;”, you access object properties with the dot “.” operator, you access array elements with the “[]” brackets, etc.). Where things differ is with the various APIs (Application Programming Interface) that are implemented to work with JavaScript. Now you have many flavours, like the JavaScript for Acrobat API, the JavaScript for XFA API, etc. On windows, you can write scripts using “JScript” which is Microsoft’s version of JavaScript extended with its own OS-related APIs. The important thing to remember is that these APIs simply make new objects and functions, specific to some functionality, available to you when you write JavaScript code and when that code is executed.

JavaScript is interpreted at runtime so it’s very difficult to tell, at design time, if you’re not using an API call correctly but there are advantages like being able to write for different APIs in the same code and using IF statements to choose which code to execute so that the code pertaining to the current context (and APIs) is executed at the right time.

As for your question about populating Form B with Form A’s data, that’s definitely a challenge and there are many ways of doing it. What you have to remember is that data is what drives a form. The form’s purpose is to show and/or collect data. What shape/form this data has may depend on a schema and you typically have one schema per form. (An XML Schema describes the structure of the data.) If Form A’s schema is different from Form B’s schema, then you have to figure-out a way to translate data from Form A’s format into a format that Form B can read. Even if you were using a database to get and set data, Form A may still have a different structure than Form B (different field names, different nesting of objects, etc.) so, at the very least, you would need script to get data submitted into the database by Form A and push it into the right fields in Form B (and that script is the translation of the data from Form A’s structure into Form B’s structure).

Aggrey,

I understand about the costs. Note that if you do not involve LiveCycle server products, you will not be able to import/export data using data connections. If you need this capability, you will have to rely on JavaScript to code the import into your form in an unsecure fashion via the URL Request. When exporting data, you will have to either submit it in XML via email and reconstitute the form on your end using Acrobat Pro or you will have to code a PHP/ASP/JSP/etc. server page to which the form can submit its data. You would submit via HTTP and write your own code to take that data and insert it into whatever back-end system your clients have.

As for barcodes, Designer ships with many barcodes which you can use as long as you have the proper scanner. The real value, however, is in the 2D barcodes which you use in concert with LiveCycle Barcoded Forms ES. If you use the 2D barcodes, data will be encrypted and you’ll need Barcoded Forms to decode it on the server. That’s not to say you couldn’t implement your own system using script and various “free” barcodes but it may be a lot of work and will likely not be as robust.

Subform-related posts:
http://forms.stefcameron.com/category/instance-manager/
http://forms.stefcameron.com/category/data-binding/
http://forms.stefcameron.com/category/data-nominated-subforms/
http://forms.stefcameron.com/category/tables/

Enjoy!

PS: I found a great online JavaScript reference at W3School. It covers the basics of JavaScript.

Hi Stefan,

I’m hoping you can help me?

I’m wondering if there is a way to programmatically associate an attachment to a Form Object Collection so that when that section of the form is digitally signed it locks the associated attachment (subsequently allowing additional attachments to be added to other Form Object Collections on the same form that have not been digitally signed and locked yet)?

This is a Form requirement I’ve been struggling with and have been unable to come up with a solution.

I know that Designer 8.2 itself is limited and does not allow this but can you suggest an alternative (maybe FLEX) that would allow me to accomplish this?

I’m contracting remotely for a client in Southern California but I’m physically located in Colorado.

Thanks very much.
Kim Miller
{scof: phone number removed}

Hi Stefan,

I am wanting to create a PDF form that a user can key information and the form will generate a 2d barcode when printed out. My user will be faxing these forms to a fax server and I will be scanning the forms to read the 2d barcode.

Can I do this with Ddesigner?

Thanks.
Calvin

@Calvin,

Yes, you can add hardware- and software-rendered barcodes to forms using the Object Palette’s Barcode panel. Designer supports a multitude of barcodes, both 1-D and 2-D.