User Guide and Reference

General Purpose

Hide Navigation Pane

General Purpose

Previous topic Next topic No directory for this topic  

General Purpose

Previous topic Next topic Topic directory requires JavaScript JavaScript is required for the print function  

Configuration Settings

 

The General Purpose Business Rule widget's Rule tab holds the following:

 

Visibility Rule
Note the difference between Always Visible, Never Visible and Script or Rule Based.
That is: the value of an invisible field being observed by the Business Rule could be affecting the outcome of the rule because the field has not been cleared.
See also Clearing Policies.
 

Visibility Policy
 

Initial Visibility
 

Visibility Data Clearing Policy
 

Business Rule
Either "None" or "Script Based"
 

Additional Event LIsteners
See here
 

Business Rule Trigger
Run Always | Run only when visible.

 

The Relationship Between Nominated Widgets and the Rule

There are two broad ways for a General Purpose Business Rule widget to fire:

 

1.The default
where the rule fires every time one of the nominated widgets changes. In other words, the rule's listener is forever observing these widgets for change and will fire every time one of these changes. This can slow the form down if the scale of all these observed widgets is large enough.
 

 

Rule fires on change of any observed widget; as a result, the rule could fire many times and make the form laggy

Rule fires on change of any observed widget; as a result, the rule could fire many times and make the form laggy

 

2.Additional Event Listeners
Here, the widgets linked to the rule can asynchronously change, but the rule will only fire when a form-level event is detected by the listener. The form events are listed, comma separated in the "Additional Event Listeners" field in the "Data" tab of the Business Rule widget.

 

Rule fires less and only on a nominated form event or events; results in a more responsive form.

Rule fires less and only on a nominated form event or events; results in a more responsive form.

 

The above second case results in the Rule widget firing less frequently than for the first case: every change to any of the observed widgets no longer results in the rule firing every time.

 

Standard Composer Events

Event

Description

init

The first event to which a widget can listen when the form starts. This event sets the initial data-based state.

postInit

Runs immediately after init. Used to run code when everything is in the initialized state.

change

The only event that does not call everything listening to it. It will look at the source node and look up the list of fields with a dependency on that field.

phase

Will fire when any phase value changes. evt.evtData is the name of the changed phase. Its new value is fetched with sfc.getPhaseValue("<phaseName>"), where <phaseName> is the name of the affected phase.

evtValidationView

This event is fired once all current validation updates have been completed and it is ready to update the error lists, etc.

preSubmit

this event fires immediately before the form is submitted (although there is an issue that preSubmit is not currently fired when using a form in Mobile App but this should be resolved in a future release).