...

In addition, the layout designer sets the RulesBehaviour and RulesMetadata properties for the window and the frame. These properties contain metadata and advanced options. There's currently no need or use cases to change these properties except when removing a ruleflow by deleting or setting an empty JSON object "{}".

Guidelines

• Make sure both the frame and window rule vocabularies were generated (if the window vocabulary was not previously generated).

Files and Directory Structure (Workspace)

...

The root directory also contains directories for every generated window or frame rule flows (with the .js files). The generated directories (with the .js files) are located in the root directory partly because this is the default location in the Corticon Generate Ruleflow dialog-box to save developers the need to change the directory manually every time.

Guidelines

• Open the Corticon.js Studio in the root rules directory, in <environment>/osiv-webui/Rules.
  
  
• All the rule files for a window or frame should be placed in a single directory with the same name (inside the correct Ruleflows category directory).
  
  
• All the rule files should start with the same name as the window or frame (there is only one vocabulary and one workflow files so they should have the same name as the window or frame).
  
  
• Every rule sheet file should have a different suffix like _IsEnabled, _IsVisible, _Pages etc. (see rule sheet design).
  For example: EntscheidDetailWindow_IsEnabled
  
  
• Rule test files should start with the same name as their rule sheet including the suffix plus _Test or _Test<number> for multiple rule tests (see rule test design).
  For example: EntscheidDetailWindow_isEnabled_Test.
  
  
• Generate the .js files directory in the root rules directory which is default location of the Corticon Generate Ruleflow dialog-box.

...

The general best practices from Progress Software is to use separate rule sheets for complex conditions with many combinations and combine simpler rules into a single rulesheet to save on rulesheets files and are also where the Check for Conflicts and Check for Completeness is less needed. In other words, it's a balancing act.

Guidelines

• Taking into account that UI rules are usually made up of many simple rules it is decided to group the rules for a window or frame into the following rule sheets and rules (which is also the same way the rule specification at OSIV divided the rules) -
  
  
  • <window>_Fixed.ers - Fixed property settings.
  • <window>_IsEnabled.ers - Rules for enabling form fields (using the <field>__isEnabled property).
  • <window>_IsVisible.ers - Form fields visiblity rules (using the <field>__isVisible property).
  • <window>_Pages.ers - Pages (tabs) visiblity rules and enabling or disabling pages.
  • <window>_Messages.ers - Message rules (errors, warnings and info messages).
    
    
• With the following exception - if there are complicated rules with conditions containing more than 5 to 10 fields and many combinations then it is recommended to put these rules in a separate rule sheets with a descriptive name suffix.
  
  
• Unrelated conditions and actions in a single rule sheet should be separated with an empty row for clarity.
  
  
• A specific property, like, a form field is enabled property (or any other property) must be set in one place and one place only. The property must be set in one rule sheet covering all the combinations, and in either the frame or window rules but never both. Setting the same property in different rule sheets increases the risk of conflicts.
  
  
• Use the default action column whenever possible to decrease the number of condition combinations and simplify the rules. For example: if you set the default for the is enabled property to false then you only need to specify the condition combination when it is true (which in many cases is a single combination).
  
  
• Use an AND condition and the default the column instead of an OR condition for setting properties (because AND conditions use a single combination column and OR conditions use multiple combination columns which helps simplify and shorten rule sheets). 
  
  
• Continuing the guidelines above the fixed rule sheet should only be used for properties that have a fixed or constant value and should not be used for default values. The fixed rule sheet can also be used for setting custom properties by calling the custom JavaScript functions to fetch values.
  
  
• In the message rule sheet, use the cellValue in the new message action and place the message in the cell for the action column.

...

Related DynSelect Setting

Guidelines

• If there are any related fields that should be updated when a dynSelect value is changed in a form or calculated fields in business entities then they should be added to the dynSelect mapping so the correct values are available for Corticon.
  
  This guideline is true when using Corticon as it is when writing TypeScript.

...