Creating Rules

Below is an indication of the different components of the Rule Designer. See the topic on Getting Familiar with the Rule Designer for definitions and detailed information on these components.

Execution types and certain controls can be configured to speed up the process of accessing a View or Form at runtime. These types are discussed below: 

The asynchronous execution type executes all actions without waiting for each action to complete. Execution continues with the next block of actions regardless if all actions have completed. This is useful for non-dependent actions and to enhance performance.

List controls such as Picker, Drop-Down List, Check Box List, Radio Button List and List Display now support loading their list values without needing a spinner blocking the entire View or Form from being accessed. These controls contain their own spinner/ modalizers to indicate that they have not fully loaded yet. The controls will store the value they are set to and return it correctly (if requested via a rule action) even before they are finished loading, allowing the rest of runtime to continue executing.  

Data requests can occur in the following instances: 

  • The control will raise the OnSet event (populate) each time the value is set regardless if the control had finished populating its data or if the value had been saved (applicable to listing controls only).  
  • The control will raise the OnSetItemsCompleted event each time the control has finished populating its data (applicable to listing controls only). 
  • The control will only raise the OnChange (change) event if it has finished populating and the value has changed from the previous value.
  • The control will raise the Resolving event which executes on load/search/resolve (applicable to the Picker control only).

List controls have an additional property called Display Field. This property allows you to show the control’s display value before its data has been loaded.  This can be used to speed up the first access time of a View or Form that loads data on Initialize. It works on the principle of denormalized SmartObjects; where you store not only an identifier reference on the main SmartObject but also the display value for the control. The list of fields is limited to properties of the main SmartObject that the View is bound to.

How to use the Display Field
The following scenario is used to explain the application of the Display Field property:

  • Create two SmartObjects called Order and Customer with properties as follows:
    • Order
      • ID
      • CustomerID
      • Name
    • Customer
      • ID
      • Name
  • Perform an association between the two SmartObjects where:
    • Each Order has a single Customer
    • Customer can have many Order SmartObjects
  • Create an Item View from the Order SmartObject
  • Create a rule with the following definition: 
    • When the View executed Initialize
    • then execute the load method
  • Change the actions execution type to asynchronous in the rule created above
  • The Customer Drop-Down List control will be bound to the CustomerID field and it will look up the Customer SmartObject and display the Name
  • Save the View, then edit the Order SmartObject
  • Add another property called CustomerName and save the SmartObject
  • Edit the View and map the CustomerName property to the Display Field property of the Customer Drop-Down List control.

When the View loads a new record, it will first load the values of Order and then populate the Customer Drop-Down List. However since there is a value for the Display Field the Customer Drop-Down List will show the display value immediately and not show a spinner even though the data is still loading in the background. When the data is finally loaded behind the scenes if the display value had changed / is no longer valid the control will update its display. To ensure this scenario behaves correctly you need to store the CustomerName each time a new SmartObject is created or saved.

The following examples show the amount of server connections made per execution type. This is specifically useful when performance is an issue and it is necessary to cut down on the amount of server connections made. 

Execution Type Rule Definition Server Connection
One after another

- Execute a SmartObject GetList method

- Then start a workflow

 2 Server connections - SmartObject GetList method executes first. Once the GetList data is returned /completed then the workflow is started
Concurrently

- Execute a SmartObject GetList method

- Then start a workflow

 2 Server connections are started simultaneously and independently with a delay until all actions have been completed within the execution block
In a batch

- Execute a SmartObject GetList method on View X

- Execute a SmartObject GetList method on View Y

 1 Server connection - Actions are grouped in a single execution packet and started at the same time
Asynchronously

- Hide a View

- Hide a control

 2 Server connections - All the actions start at the same time, when the first action completes the second execution block starts

View Rules can be set up to execute independently from Form Rules, but they can also be used to add on to in a Form. If a View Rule is created in the View Designer, this rule is available for editing in the Form Designer's rules section. When the View rule is changed on the Form, it does not modify the rule on the View. However, if the rule is changed in the View Designer for the rule that was previously overwritten in the Form, the change to the View rule will apply to the rule on the Form. The Form rule therefore inherits the View Rule and will see the changes made, but will still apply the previous change made to the View Rule on the Form as well.
A Rule Definition that was created in the View Designer can be enabled or disabled in the Form, but not be removed from the Rule. Only Rule Definitions that belong to the specific designer can be removed in that designer.
See the Rule Inheritance Example for a more visual explanation

Rules can be enabled or disabled in the Rule Designer. This is useful when having different Form states or opening subviews or subforms for example and certain Rules are not required.
When a Rule is disabled, the text of the Rule changes to grey and the icon of the Rule changes as seen below to indicate that the rule can not be edited. Enabling the Rule will restore the icon and change the text to black.

It is however important to note the influence enabling or disabling Rules have on Rule inheritance. 
If a parent View is opening a subview for example which inherits the Rules from the parent View, and changes are made to the Rules on the subview, the Rule inheritance to the parent View is lost.

The following need to be considered when disabling a Rule:

  • Changes to the parent View/Form, such as adding/removing/editing of Actions or Conditions will still be applied to the child. However enabling or disabling Rules will not be applied to the child as the inheritance is lost.
  • When a Rule is disabled all Actions, Conditions and Events contained within that Rule is also disabled.
  • When a Rule is disabled the Rule can still be removed but it cannot be edited.
  • If a Rule is disabled and it contains an Action to execute another rule, that rule will not be executed as the parent rule is disabled. 

See the following links for more information or examples on Rules and Rule Inheritance:

Related Topics

How to change when Actions execute in the Rule Designer