Recently in Designer Category

As we discovered in Part 1, an Action is a list of Conditions, and a list of Results. Lets take a look at the Conditions. What choice are available in a particular condition row depends on the type of object you selected. A new, empty condition row just asks you to pick a node:

Click on "(object)" and a dialog appears with a list of all the nodes in the form that support conditions:

We saw previously that if you choose a button, you don't get any further choices:

But let's choose the Decimal Field:

Ah, more options. The condition and result rows are designed to read somewhat naturally, so although the spacing is a bit weird, it reads understandably.

Note that once you pick an object type for a condition row, the type is set - if you click on "DecimalField1", the object picker window will only show you other decimal fields. If you want to start over with an empty row, hit the red minus button at the right of the row.

Here's the complete list of conditions for a decimal field:

Some of these are more obvious than others, and the mapping from Actions to the XFA scripting events that exists under the hood is intentionally blurred a bit. For example, "is initialized" is pretty obviously related to the "initialize" event for fields, but what event does "is not" map to? That's where Actions starts to get interesting.

This set of conditions will fire when the value entered into the field is >= 10 and <= 20. These two condition rows wind up generating a single line of script in a single event - DecimalField1's change event. With Action Builder, you express your intentions and Action Builder figures out what code to write and where to put it.

This time the two condition rows each reference a different object: TextField1 and TextField2. This results in script being generated in the exit event of both TextField1 and TextField2.

But some conditions can't be checked with an "and" relationship. For example it doesn't make any sense to say "When Button1 is clicked AND when Button2 is clicked", because you can't click two buttons at the exact same time. If you try to create an Action that we can't generate script for, we will try to tell you why:

Stephanie is going to talk more about trigger conditions and state conditions over on the LiveCycle Designer Exposed blog, so make sure you're subscribed to that as well if you're interested in this ongoing Action Builder saga. One last screenshot:

Next time, we'll talk about results.

Now that the next version of LiveCycle ES is in beta (some info here and you can join here), we can start talking about some of the new features that we're planning to deliver in LiveCycle Designer, the form design tool that's part of LiveCycle. We've been working on a lot of interesting things.

One of the themes of this version is form simplification. By simplification I don't mean making simpler forms - I mean making it easier to make complex forms. Reducing the amount of script you have to write, for example, while giving you even richer ways to validate data and show validation problems, and build interaction into your forms.

Validations in particular can account for hundreds or even thousands of lines of JavaScript code in complex forms, but with the new Designer, much of this script is no longer necessary!

And let's say you wanted a form that had an optional section, with a checkbox that would show or hide that section. In Designer 8.2, this required writing script. Now? A few clicks and you're done. We've built a way for you to write script for the most common types of form interactions that we see in dynamic forms, without having to write script.

It's called Actions, and there's a sneak preview over at Mark Szulc's blog.

Between now and when the new Designer is released, you'll see some members of the team posting about new features. It's great to be able to talk about them and I hope you find them useful.