Archive for the 'XFA' Category

Submitting Form Data by Email

Thursday, August 28th, 2008

A frequently-asked question is, "how do I modify the email in an email submit button?" Usually, the reason behind the question is that a form should either be routed to a specific person depending on data entered at runtime (so you can’t predict the data and therefore you can’t set the email submit button accordingly at design-time) or perhaps the form even presents a list of possible recipients and the user must choose which person to send the submission data to.

The Secret

The secret to changing the email recipient for an email submit button (or even changing it for a regular button which you’ve turned into a submit button using the "Object palette > Field tab > Control Type > Submit property") is to set the "target" attribute of the <submit> node that is part of the button’s Click event. The "target" specified the URL to which the data will be submitted. HTTP and mailto are valid protocols.

In XFA, the difference between a regular button with Click event script and a submit button which submits form data when it’s clicked is that the submit button’s Click event has a <submit> node instead of a <script> node.

A regular button’s Click event:

<event activity="click">
    <script contentType="application/x-javascript">
        // your JavaScript code here...
    </script>
</event>

versus a submit button’s Click event (set to email form data in this case because of the "mailto" protocol):

<event activity="click">
    <submit format="xml" textEncoding="UTF-8" target="mailto:"/>
</event>

How is it done?

Changing the recipient is done simply by setting the submit button’s target appropriately, following the rules of the protocol you wish to use. In this case, we’ll be using the mailto protocol. Of course, we can do much more than change the recipient: We can actually specify multiple recipients, CC some others, BCC others still, specify any subject we want and even specify a customized email body (message)! All that needs to be done is to apply the mailto protocol when specifying the submit button’s target.

For example, setting the target to the following string would create an email with two recipients (one "to" and one CC’d), a subject and a body:

mailto:john@asdf.com?cc=lisa@adsf.com&subject=Re: New Account Opening&body=Thank%20you%21"

Note that the body must be URL-encoded using the "%" codes for non-URL characters such as "%20" for a space and "%21" for an exclamation mark (!). Thankfully, we can use the encodeURIComponent(string) method in JavaScript to do that part for us!

The most difficult part of all this is finding the Click event (since there could be multiple <event> nodes specified on a single field, one for each event that does something) and locating the <submit> node inside.

Sample Form

To illustrate how this is done, I’ve created a sample form that submits an address block as data and provides fields for specifying the recipient(s), CC list, BCC list, subject and body of the email.

The result of the above settings is a new email with the specified recipients, subject and body, along with the attached XML data file:

 

In order to accomplish this, I used the two-button submit technique where a regular button is used to set the properties on a hidden email submit button. Doing it this way also lets me easily prevent the submission if there are no recipients ("to") selected. (Note that the To, CC and BCC fields are multi-select list boxes so you can choose multiple email addresses.) You’ll be interested in the script in the "Send" button’s Click event.

Download Sample [pdf]

Minimum Requirements: Designer 8.0, Acrobat/Reader 8.0 for this form since it uses functions that are part of the new List Object API which was introduced with the 8.0 versions however you could access the selected items differently and get this to work in previous versions as well.

XFA 2.7 Spec Now Available

Wednesday, March 12th, 2008

In toe with the recent release of LiveCycle ES SP2 comes the availability of version 2.7 of the XFA spec. There aren’t any significant changes that I can think of in this release but I thought you might want to know about its availability nonetheless.

XFA 2.7 is supported by LiveCycle Designer ES 8.1.2.

XFA 2.6 Spec Now Available

Wednesday, March 5th, 2008

I was just looking at the Adobe XML Forms Architecture (XFA) web page and noticed that the XFA 2.6 spec was posted recently (near the end of January 2008, I think). I have to admit I didn’t expect to see it there for a while still but this is a good thing!

XFA 2.6 is supported by LiveCycle Designer 8.1 and Acrobat/Reader 8.1.

Presence vs Relevance

Thursday, September 27th, 2007

Designer 7.1 introduced the ability to specify whether a button was visible only on the (computer) screen, only on paper (print) or both (visible all the time). This feature, supported in conjunction with Acrobat 7.0.5, was then extended to all XFA objects (text fields, check boxes, lists, etc.) in Designer/Acrobat 8.0.

Unfortunately, how the two concepts interact is something that isn’t easy to grasp at first and so I thought I would delve into the details and attempt to clarify things.

Note that in this article when I write about Acrobat I include Reader as well.

Before Relevance

Prior to the concept of relevance, an object was either visible, invisible or hidden, as specified by the presence attribute and it didn’t matter whether the form as being rendered on a computer screen or printed on a piece of paper — it could either be seen or not.

One of the problems with this approach to presence surfaced when you wanted to design a form that had a submit button for the electronic “fill & submit” workflow but you also wanted to support the manual “fill, print & mail” workflow. When the user printed the form, they would get this submit button on the print-out which was completely useless and looked out-of-place.

In Designer/Acrobat 7.0 or earlier, if you wanted to prevent the button from printing, you had to resort to scripting the button’s PrePrint and PostPrint events in order to hide the button while the form was being printed:

PrePrint

this.presence = "invisible"; // or "hidden";

PostPrint

this.presence = "visible";

Relevance in Designer 7.1 / Acrobat 7.0.5 - 7.0.9

The advent of Designer 7.1 and Acrobat 7.0.5 introduced support for ”relevance” on button objects only. Relevance lets us further define the circumstances where an object is visible.

There are currently two supported “views” to which objects may be relevant: Screen View and Print View. They are both straight-forward: The Screen View represents the form as it is seen on a computer screen (in Acrobat or a browser) and the Print View represents the form as it is seen on paper (after being printed).

The following table illustrates the view(s) in which a form object is visible given values assigned to an object’s presence and relevant properties. For instance, if an object is defined as follows in XFA

<field presence="invisible" relevant="+print">...</field>

it would be included (”in”) only in the Print View.

Relevant Presence Screen View Print View
+print visible in in
-print visible in out
+print invisible out in (visible)
-print invisible out out
+print hidden out out
-print hidden out out

Note that if the relevant property isn’t specified, the presence property controls the object’s inclusion in both views at the same time (as was the case before the introduction of the “relevant” property).

More importantly, notice how setting the presence property to “invisible” and the relevant property to “+print” actually causes the object to be visible in the Print View (rather than invisible). This wasn’t the original intent and was corrected in Acrobat 8.0+.

Relevance in Designer/Acrobat 8.0+

The 8.0 versions not only added support for presense and relevance on all objects (text fields, list boxes, circles, squares, text, subforms, radio button lists, etc.) but they also corrected the results of some presence and relevant property combinations such that the two are now disjoint: The relevant property determines the view (Screen and/or Print) to which an object belongs and the presence property then controls the object’s visibility within that view.

The result is as follows (note the differences highlighted in blue between both tables):

Relevant Presence Screen View Print View
+print visible out in
-print visible in out
+print invisible out in (invisible)
-print invisible in (invisible) out
+print hidden out in (hidden)
-print hidden in (hidden) out

As in previous versions, the omission of the relevant property gives control to the presence property in both views.

Setting Presence and Relevance in Designer 8.0+

Designer exposes presence and relevance via its presence property in the Object palette. It combines the two into the following settings:

Designer XFA Relevant XFA Presence
Visible <not specified> visible
Visible (Screen Only) -print visible
Visible (Print Only) +print visible
Invisible <not specified> invisible
Hidden <not specified> hidden

Differing Behaviors Across Acrobat Versions

Remember that the results of the relevant and presence property combinations are specific to the version of Acrobat being used to view/print the form.

For example, if you designed a form with a button that had

presence="invisible", relevant="+print"

it would be excluded from the Screen View but visible in the Print View in Acrobat 7.0.5 - 7.0.9. However, if you were to open the same PDF form in Acrobat 8.0+, the button would be invisible in the Print View.

XFA 2.5 Spec Now Public

Tuesday, June 19th, 2007

I was just notified that the XFA 2.5 specification has been posted to the Adobe LiveCycle Developer Center. For many of you, this is the end of a very long wait, I’m sure. Hopefully it contains all the information you’ve been looking for.

XFA 2.5 is supported by Designer 8.0 and Acrobat/Reader 8.0.