Many of you have been requesting some debugging features for XFA Forms (and I’m sure many more of you just haven’t voted for it yet). It so happens that Acrobat Pro has a JavaScript Debugger which can be used — to a limited extent — with XFA Forms. See John Brinkman’s post to learn more about it — thanks John!

As he puts it, there are limitations, the biggest ones of them being, in my opinion, the inability to debug script objects and the inability to retain breakpoints between debugging sessions. Nonetheless, this tool can give you way more insight than the good old “JavaScript Console + saveXML(‘pretty’)” combination can in certain cases, and it does it in a nice tree to boot!

Paul Guerette, a colleague of mine at Adobe, will be giving a “tech talk” eSeminar on connecting forms to databases over at AcrobatUsers.com on Tuesday, March 23, 2010, at 10am PST (1pm EST).

If you have been struggling with connecting a form to a database, are wanting to know what the best practices and/or security concerns are, or have some specific questions you would like to ask, I highly recommend you attend the session. It’s free to attend (and free to become a member in order to attend)!

I’ll be answering chat questions “live” as the session unfolds. I hope you can join us!

I thought I would point-out a nice improvement that was made to XFA <subform> elements back in XFA 2.8: The addition of the access property.

In days of yore, if you wanted to disable all fields and exclusion groups (for the sake of brevity, I’ll refer to these collectively as “fields” in this article) in a particular section of your form, you would’ve had to write a script that recursively drilled down into all children of that section looking for fields to disable. This is because the access attribute only applied to fields.

With this change, assuming the section in question is contained within a subform, you can now easily disable all fields contained within it simply by setting the subform’s access attribute to “readOnly”!

The following table describes the four levels of restrictiveness (in XFA 2.8, from the highest level to the lowest) that can be imposed on fields using the access attribute, either directly on a field or by a parent subform:

When a subform imposes restrictions on the fields it contains (meaning all fields within any level of nesting, not just immediate children), the inheritance on child fields and subforms follows that of the most restrictive parent imposition. For example, if a subform imposes access=”protected” and a child subform has access=”readOnly”, all of the inner subform’s children, including the inner subform itself, will effectively have a “protected” access level.

The explanations of the various access types in the table above are summarized. “Access Restrictions” on page 48 of the XFA 2.8 specification has more precise, albeit more technical, explanations of each level of restrictiveness.

Setting Access by Script

Setting the access attribute of a field or subform by script is simple, both in JavaScript and FormCalc:

// set access level to read-only:
FormObject.access = "readOnly";

If you wanted to disable all fields in the entire form with a single line of script, you would simply set the root subform’s access attribute to something other than “open”, as appropriate:

// if the root subform's name is "form1":
xfa.form.form1.access = "nonInteractive"

Did you know you could quickly access the Preview tab in the Form Properties dialog from the PDF Preview tab’s context menu?

My friend Angie Okamoto (Easel Solutions) was the one who originally pointed this out to me. It’s incredibly useful, especially when you’re switching between various preview data files (or options like interactive vs non-interactive), because it loads the dialog and activates the Preview tab in a single step. This saves both mouse travel time and one click which adds-up to a lot, if you do this frequently.

Right-click on the PDF Preview tab to get the context menu:

Choose “Form Properties” and you’re right on the Preview tab:

Another option is to set a Shortcut Key for the Form Properties dialog, though this won’t auto-select the Preview tab (but still saves some mouse travel and a couple of clicks). You can do this via the “Tools > Keyboard Shortcuts” dialog:

Unfortunately, I don’t recall what version of Designer introduced the PDF Preview tab’s context menu nor which one added Keyboard Shortcuts but I think both should be available since version 8.0.

Did you know that you could insert a line break, as opposed to a paragraph break, in between two lines in a text object using the [Shift + Enter] keyboard sequence?

When editing the contents of a text object, pressing the [Enter] key will produce a paragraph break which means that any Above and/or Below Spacing you have specified will come into effect, amongst other paragraph formatting-related properties. Under the hood, the effect is the insertion of a “new line” character (\n) in a plain text object or a new <p> tag in a rich (XHTML) text object.

Sometimes, however, you need to break a line without producing a new paragraph. For example, you might have a long URL to insert and, given its position within the contents, it ends-up being broken onto another line and you would prefer to keep it on a single line, yet part of the same paragraph. To do this, use the [Shift + Enter] keyboard sequence. The result is a “soft” break to another line without moving to a new paragraph. Under the hood, this translates into the insertion of a U+2029 Unicode break character in plain text or a <br> tag in rich (XHTML) text.

Those of you using a version of Designer which precedes the 8.2.1 release should note that when using [Shift + Enter] in a plain text object, the contents of the object gets converted into rich text since previous versions of Designer would always use the <br> tag to denote a line break. Designer 8.2.1 coincided with the release of Acrobat/Reader 9.0 which provided improvements to the Text Engine in order to support the plain text U+2029 Unicode break character.

Line Breaks in Acrobat/Reader

What I describe above relates to the authoring experience in Designer. Inserting line breaks (as opposed to paragraph breaks) while filling a form in Acrobat/Reader is different. John Brinkman explains the “why and how” in this post.

Sample Form

Download Sample [pdf]

I have included a sample for that demonstrates the different types of breaks in both plain and rich text objects. I also included a text field that has a multi-line rich text caption (the contents of the rich text object) and a multi-line default value (the contents of the plain text object), both using paragraph and line breaks. (If you’re wondering how I got those values into the caption and default value properties, I used good old Copy & Paste in both cases.)

Minimum Sample Requirements: I authored this sample using Designer 8.2.1.2 and Acrobat 9.3. It should work back to Acrobat 9.0. I’m unsure of the results in earlier versions of Designer and Acrobat due to the use of the U+2029 character in plain text.

The LiveCycle Product Blog has some recent information on the availability of the Designer ES2 Upgrade which can now be purchased on the Adobe Store.

Note that, going forward, Designer will no longer be available for purchase apart from Acrobat Pro or Workbench (i.e. you will no longer be able to purchase Designer without purchasing one of these two other products).

The Adobe Reader Blog has a recent post describing what’s new with these security updates. Amongst other things, there is now a JavaScript Blacklist Framework which “provides customers granular control over the execution of specific JavaScript API calls.”

There is also an 8.2 update to Acrobat/Reader which includes some of these features as well.

Hello everyone,

I trust you’re all ready for the new year/decade ahead of us! I’ll be catching-up to comments over the next couple of weeks and hope to be posting some new tutorials soon.

Happy New Year!

Stefan

Hello everyone,

I will be taking a break from blogging from now until the new year.

I hope you will enjoy the holidays! I will return January 4, 2010.

Stefan

While recently helping a few people with some issues related to HTTP submissions from XFA forms, I ended-up creating new Data Service that helps with testing HTTP Submit Buttons.

The service is quite simple: It displays what you submit to it. Since Designer’s “PDF Preview” tab is actually an instance of Internet Explorer hosting a PDF version of the form you’re previewing (a temporary PDF if your form is saved as an XDP or is new), the results are conveniently displayed within the tab itself after clicking on the submit button.

To use the service, simply use either an http submit button (or a regular button with its “Object palette > Field tab > Control Type property” set to “Submit”) and set its URL to:

http://forms.stefcameron.com/services/http-submit-test/

The idea is to use this service as a means to test/debug your forms before spending time writing the actual server code that will receive the data. You can also use it to ensure that you are submitting the correct data to a third-party service (for which you don’t control the server-side code).

Choosing a Submit Format

HTTP submissions can be made in various formats: XML, XDP, URL-encoded (HTTP post), and PDF. If you are using Reader instead of Acrobat, you will not be able to submit in PDF format unless you have enabled this ability using LC Reader Extensions.

The most important difference amongst the formats is that repeating data sets cannot be submitted using URL-encoding (HTTP post). This is due to the way the data is submitted: In HTTP post directives, data is submitted in “name=value” pairs. Since repeating data sets involve hierarchy and duplicate data node names, only the last instance of the repeating set will be submitted.

To submit repeating data sets, you must choose either XML, XDP or PDF as the data format.

Sample Form

The following sample form demonstrates the use of the HTTP Submit Test service.

Download Sample [pdf]

The form has a typical address block as well as a table to demonstrate both static and repeating data sets. Use the submit buttons to try submitting in different formats (XML, XDP, PDF, URL-encoded). Notice how only the last table row is submitted when using the URL-encoded (“post”) submit button.

Minimum Sample Requirements: I created this sample using Designer 9.0 and Acrobat 9.2 however it should work fine back to Acrobat 7.0.5.