Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Section
Column

Business rules are added by editing your form or workflow. Click the Rules icon in the form designer toolbar shown below to add new business rules and edit any existing rules in your form.

You may create a new rule by clicking on the icon. Your new rule is given a randomly generated name. You can edit the name as described below.

Each rule has three icons. Each is described below.

  • Click the icon to edit an existing rule. You can edit the name, description and statement (JavaScript code) for the rule.
  • Click the icon to delete a rule. Confirm your choice in the dialog that pops up and the rule will be immediately removed. This is an irreversible process so make sure you do not need the rule before you delete it.

Rules can be temporarily disabled by unchecking the ''enabled''' checkbox visible by opening a rule for edit.

Refer to Rules Examples for many real world samples.

Column
width340px

 On this page:

Table of Contents
maxLevel5

...

  • form.load : This property is true when the form is first loading. It is useful for setting default values via rules that you need to be set before the user starts interacting with the form. This also holds true for flows. This property is true when each step of a workflow is first loading.
  • form.unload : This property is true when users click the form's submit button. It is useful for setting control values just prior to the execution of the form's Doc Actions and Form Actions. This also holds true for flows. This property is true when the user clicks the continue button for each workflow step.
  • form.positionUpdated : This property is used for the Geo location feature. You can fire a rule using this special identifier every time the position is updated.

Examples of identifiers used in  rules are:

...

Business rules are executed on the  server-side and not as client-side javascriptJavaScript. There are several reasons why rules execute server-side:

  • Browser independence. We found it impossible to get these to run reliably in so many versions of so many browsers, especially IE. A bug in your rule (e.g. an infinite loop) will crash the browser and in some cases will require a Windows reboot. On the server, these run in separate threads with lower priority and timeouts so it will not impact the form server.
  • The ability for the rule to do server-side things like http:get () to a database connector, invoke a REST service etc. These often reside behind the firewall and are not accessible to the browser.
  • The rules are not exposed to the browser at all so any sensitive information in the rule (e.g. a password) won’t leave the server. However, we do not recommend putting any sensitive information in a rule.
  • Rules can use information like the currently authenticated subject user id, name, email etc. though technically it would be possible to make this available on the browser if required. However, providing this information in the browser is a potential security hole.
  • Rules can also modify a control – in theory, this can cause large-scale changes to the form’s valid state. Think of an optional XML complex type that has a deeply nested data structure inside it with some required and some optional elements. If any element has a value, all the other required elements become required. It’s much easier and efficient to analyze the form on the server although, technically, this is also possible in the browser. It can be extremely slow for large forms, especially in IE or if someone is running on a slower machine.

These pros of excuting rules server-side mitigate the couple cons:

...

There is a potential for performance bottlenecks. However, this is rare since rules are not compute intensive typically. We think the benefits outweigh the drawbacks here.

Dates and Times

There are several special considerations when writing rules using date, time and date/time controls. You can also find many working samples in the Rules Examples chapter.

...

You can retrieve custom attributes from Active Directory using the com.frevvo.security.ldap.customAttributes configuration parameter and  business rules. When a user is successfully authenticated by the LDAP security manager, Live Forms retrieves the Last Name, First Name and Email Address for the user from the LDAP server:  

The designer can use built-in methods in a rule to populate controls on a form. The rules use the  the _data.getParameter syntax, For example, the business rule shown fills the respective form fields with the First/Last Names and Email Address of the logged in user. 

Section
Column
width50%
Code Block
if(form.load)
{
EmployeeEmail.value=_data.getParameter('subject.email');
FirstName.value=_data.getParameter('subject.first.name');
LastName.value=_data.getParameter('subject.last.name');
}
Column
width50%

You can retrieve additional custom attribute information from the LDAP server using a configuration parameter and business rules. First, you must configure the "com.frevvo.security.ldap.customAttributes" context parameter as explained here. Then write a rule to use that information in your form. For example, This rule populates the Middle Initial and Home Phone fields in addition to the First Name, Last Name and Employee Email controls. 

...