Optimizing Performance

   Composer This topic is related to Transact Composer.  |   Form Builder |  v4.3 & Higher   This feature is related to v4.3 and higher.

Overview

Forms in Composer are smart: they are dynamic and user actions in filling out the forms trigger events and change the form on-the-fly as users enter data. For example, a user can click on a checkbox and a number of fields become visible as a result. Or users fill in numerical values in a table column and a total is displayed in a field at the foot of the table.
Many forms in the real world elicit a great amount of information from the end users, with the consequence that a number of events ripple through the form as users complete entry into individual fields.
Why are there so many events on these smart forms? They are there to:
ensure that, as a default, all the data and all the dependencies on the form operate with complete integrity all of the time
ensure that all validation rules and scripts have occurred
ensure that any changes made at any time during the filling out process to any fields in the form affect all objects on the form
This design approach means that calculations, scripts and dependencies produce predictable and consistent results and that the data presented to end users is accurate and up-to-date. These take place without the form's designer doing any further work. But, as is often the case with a "one size fits all" approach, there are trade offs in large, complex forms:
an increase in generation time for very large forms an increase in the rendering time of the form
increased lag for the user to move from one field to another in such forms
increased lag when some action takes place, such as navigating through the form, submitting, saving it.

Form Generation

A full discussion of this topic is beyond the scope of this guide. The form's HTML is not statically stored in Transaction Manager and just downloaded to the end user. Instead, a number of processes take place:
the form's dependencies are inspected, resulting in a hierarchy of triggering and firing the form is prepopulated with data while being served
server-side processes to track the form from its being served to its outcome (submission, saving, abandonment, anonymous sharing or progression through a collaboration)
and even all the web server processes to deliver all the assets of the form to the user's device

Form Rendering

This is the time it takes for the device to render the form in either the browser or in the Mobile App. The form is served to either as HTML5 code interspersed with JavaScript. The JavaScript code is not merely the scripts you have placed into some of the form's fields through the Script Editor: there is also much code to integrate the form and your scripts together, as well as the functioning of the other form widgets. All these scripts and HTML have to load and initiate on the device. Most mobile devices are slower than desktop devices — although they are getting faster.
Be aware that the whole form downloads to the device, not just the visible or editable parts of the form. The same is true for all the prepolutation data, all of the form's autosuggest data (as distinct from such data provided by an external dynamic data service) and even mobile device responsive elements normally not visible on the desktop. All of these affect the rendering times, but the good news is that the increase in processing speeds of devices, and the huge performance increases in modern browsers, rendering times are no longer the problem they once were.
In the end, you must always take the user experience into account, and this may lead you to simplify your forms as a general rule.

Speeding up Generation and Rendering

It follows that these two, generation and rendering, depend mostly on the complexity of the form itself. A couple of settings in Composer have a minor influence on form generation (as we will see below). The form rendering times for the most part on the amount of HTML and JavaScript code to be processed. Optimization of rendering really means simplification of the form — just as with any other web page.

Optimization Strategies

Composer now has tools to improve the performance of forms while they are in use. Most forms of medium to low complexity require no optimization at all and run fast enough for users to have no issues. This may not be the case with very complex forms with a great deal of dependencies.
There are a number of possible strategies for tuning complex forms to run faster:
Tuning the dependencies
Tuning the triggers that make scripts fire Tuning the events that make scripts fire
Tuning the observers watching form objects and events Use of the Business Rules widgets on the form

Tuning Dependencies

Inspecting Dependencies

The Edit Properties dialog now allows you to inspect a form element's dependencies through "Edit Properties -
> Dependencies tab". The tab has 2 panels:

My Rule Dependencies

which lists the form elements on which depend this element's the Rules or Scripts. In other words, this panel shows the rules, scripts that fire and affect this element's value upon the change of any of the elements listed.

Triggered Rules

which lists the rules or scripts which fire upon this element's change.

Here is an extreme case, where we have deliberately created so many dependencies on the form that moving from field to field takes more than 10 seconds each time. The form has 30 wizard-style pages. Each page has a static tables of 10 rows, 3 columns each. Each row has a calculation, in the 3rd column, of column 1 multiplied by column 2. At the bottom of each page is a subtotal of all 10 calculation fields. The last page of the form is a total of all 30 subtotals.
This means that the total on the last page is triggered by any changes in some 91 times 30 fields, i.e. the field is triggered by changes to any one of 2,730 fields. Let us focus on just the subtotals triggering the total:

Dynamic vs Static Dependencies

When you write a script in the script editor of the Edit Properties dialog, you reference a form object using a Parameter. This creates a dependency, which duly appears in the My Rule Dependencies panel of the Dependencies tab.
The default setting for these is to have a Dynamic trigger type, as indicated by the presence of the lightning arrow in the left-hand column of the Dependencies table of the Script Editor:


A dynamic trigger type means that the script will fire whenever the field referenced changes. That means the field is always watched and the trigger will always fire on any change to the field.


Changing the trigger type to Static means that the widget will no longer be observed. So, if we change all the dependencies in the above example to the Static trigger type, the rule will not fire. That we do want the rule to fire sometimes goes without saying, because we want the total to be the correct value. Which brings us to the Trigger Conditions tab in the Script Editor.

Trigger Conditions

Here, the widgets are only read when particular form events occur. We can specify the events in the Triggering Conditions tab of the Script Editor:



But the problem here is that all the parameters listed in the Parameter Changes list have dynamic triggers. That means the settings below the list will are not reduce the firing events by very much: the rule will fire on the Parameter Changes listed. So, as a demo, we have changed all the parameters but one to static, and set them to fire only when the user moves to the wizard page with the field containing the script or just prior to submission. Of course, in practice, you would most likely, in this case, turn all the trigger types to static to give you complete control over the script firing by eliminating the dynamic triggers.

And, the reverse also applies: you can then set the triggers from the form element with the script to the widgets dependent on the script (the widgets on the right hand side of the diagram with the form event) to also be static through the Script Editor of each of these widgets.
You can see that we can now, by going through the triggering conditions throughout the form, reduce the triggers from the original 2,730 fields to a much smaller number and substantially improve the performance on this form.
You might want to leave a parameter or two still with dynamic triggers: these could be a checkbox or button, whose action is to fire the script. In earlier releases of Composer, there were some work arounds to control the firing of scripts. These included having hidden a checkboxes (to act as a Boolean to make the script fire) or using blocks as a parameter reference (in the absence of static triggering). These are now deprecated.

Trigger at Initialization

You can turn off this option and the form will render in the browser. This would only make rendering perceptively faster if the script is compute intensive. It is not worth doing for the majority of scripts. But note that the setting is not global: it applies only to this script. Also, make sure that you are not creating issues that by not running this script.

Phase Changes

The events listed in the Triggering Conditions tab are self-explanatory. Phase Changes may not be.
A phase is a non-localized variable that holds some value and which can be observed for whatever purpose. It is non-localized because you need not reference it through either a relative or absolute path.
Here follow some brief notes on creating a phase.
Pick up a "Phase" Widget from the palette (use Search to find it) and drop it onto "Nuts & Bolts -> Phases" in the Structure Panel. In the resulting wizard, it is usual to check the "Exclude from Layout Manager" as the widget normally does not appear on the form.
The Phase is configured in the Data tab.


Put any scripts required in the Rules tab, as per usual. In other scripts, you can reference the phase by
pointing to the structure widget as a Parameter or by src.getPhaseValue("phase name") as before.
Make sure you check the Phase Change checkbox in the Triggering Conditions tab of the scripts you want to fire on phase changes.

Additional Events

You can also type in the names of other events. The standardeventsarelistedhereinthisguide.

Caveats

As you can see, these tools are powerful and require no programming as such.
However, as we have mentioned above, after optimization, you must test the form to see if the scripts yield the correct answers now that changes to field values no longer ripple through the entire form automatically. There are also other undesired effects that you must guard against, such as preventing validation rules from firing and therefore letting invalid data through to submission.