On Load: Difference between revisions
Marek Rodak (talk | contribs) |
Marek Rodak (talk | contribs) |
||
| Line 22: | Line 22: | ||
== Forms == | == Forms == | ||
Form is a screen in the application that contains numerous fields which either hold or await the data | Form is a screen in the application that contains numerous fields which either hold or await the data. Default behavior of an entity form can be changed using form rules. Form rules describe sequences of steps that are executed on form-related events. | ||
;On Load execution | ;On Load execution | ||
Revision as of 13:35, 6 September 2022
| Rules and examples |
|---|
|
| Warning | Work in progress! We are in the process of updating the information on this page. Subject to change. |
Rules are client-side scripts that are executed when a user of the mobile app interacts with the app. Rules are no-code business logic, which are managed using the rules editor, usually in Woodford. The On Load rules are checked when you open a form or a questionnaire.
On Load rules are available for the following user interface components:
Use On Load for initialization
On Load rules are the best option when it comes to handling initializations. They are designed and should be used for various steps handling actions connected to the initialization of components or form styles. The reason for this is simple – users must wait for the On Load rule to be fully executed before they are able to see the form in the desired format. By setting up only the initialization actions in the On Load rule, its execution time is minimal (unless you are handling a great number of conditions and steps in the rule).
These are the recommended steps in On Load rules:
- Hide/show fields
- Enable/disable fields
- Hide/show form tabs
- Assign styles to fields or to the entire form
- Automatically assign values to fields, e.g. date & time, location, company number, etc.
Do not set up hide/show/enable/disable fields and tabs dynamically. The actions related to changes on a form while working with it are better set up in the On Change rule.
Forms
Form is a screen in the application that contains numerous fields which either hold or await the data. Default behavior of an entity form can be changed using form rules. Form rules describe sequences of steps that are executed on form-related events.
- On Load execution
- Executed right before the form is displayed on the screen. It occurs immediately after the user chooses to open an entity record from the List view screen.
Caching forms
Form caching is a practice reuses forms. When opening a different record, only the data is replaced; tabs that were collapsed stay collapsed, fields that were hidden remain hidden, etc. Problems may occur if you're using (poorly written) business logic that relies on the form being in the initial default state.
| Warning | Always remember to add Else if condition at the end of the rule, to reset the form to default state. |
Example: Hide email field
If the field Don’t Allow Emails is set to "Do Not Allow", make Email field not visible on the form.
Example: Change style on Form
If the Rating belongs to category "Hot", assign "HotLead" style, otherwise set "Normal" style.
Questionnaires
On Load rules in questionnaires are often used to automatically fill in certain fields, for example, the name of the inspector or the inspection date.
- Rule execution
- When when you open a questionnaire.
- When a repeatable group is repeated.
Example: Automatically filled fields
You might want that some fields are automatically filled in when a user starts the questionnaire.