|Tweak, Enhancement or practice||Background and Notes||Learn More|
|Use Server-Side rules to prepare forms and views before they are sent to the client browser.||You can use server-side rule actions to prepare a view or form before it is sent to the client browser, for example to pre-load a view with data, or to show and hide controls before the form is displayed on the browser. This helps to reduce the time it takes to load and display a SmartForm since some of the work is already done before the Form is shown to the user.||Server Rules|
|Execute actions asynchronously (batch or concurrent) where possible||Executing actions in batch or concurrently can significantly speed runtime performance, especially in forms with multiple views. You can combine different execution types in a single rule as well.|
one after another ("then"): sequential
Separate calls and connections to K2 Server for each action, and each action "waits" for the previous action to finish before it starts. This approach is usually the slowest, but users can work on one item while the other is busy loading.
concurrently ("and"): in parallel
Separate calls and connections to K2 server for each action, and actions return independently of each other. This approach often results in the fastest user experience, but at the cost of network data transfer. You also cannot pass values between views or methods with this approach, since you cannot predict which method will return first.
in a batch ("also"): single job
Single call and single connection to the K2 server with a batch of tasks. The batch is finished on the K2 server before the results are returned to the form/view. This approach results in less data transfer over the network, but the UI can appear locked" while the batch action is performed. This option is the most efficient for reducing network communication, and you can still pass values between SmartObject methods in the rule.
|Video: Execution Types in SmartForm Rules|
Video: Combining different Execution types in a Rule
How to change when Actions execute in a Rule
|Use hidden controls to launch subforms/views that are used more than once in a form||When reusing the same view or subform multiple times in a parent form, the parent form copies the rules of that subform/view for every rule where you call the view or subform. To avoid this overhead and bloat, use a hidden button action to launch the view/form with different inputs so that the subform is only imported once. This also helps to simplify maintenance of the parent form.||Video: Using hidden controls to open SubForms|
|Enable paging for read-only list views||When using read-only List views for larger datasets (>50 records), enable paging for the list view to limit the number of records returned on the view load. You can adjust the number of records per page in the view rules. Since paging is performed on the K2 server, this can save the amount of data transferred to the client at runtime.||Video: Using paging on read-only list views|
|Filter data as close to the source of the data as possible||Where appropriate, use server-side filtering to limit the data returned to the SmartForm. You can define the filter in the view, or if you have static filtering requirement, implement a method with a static-value parameter in the SmartObject definition. |
Some service brokers (for example the SQL service broker's "use native execution" option) that offer additional performance improvements.
|Video: Using native SQL execution to improve performance of SQL-backed SmartObjects|
|Execute SmartObject method can be faster than Execute a View method||When a form needs to retrieve a value from a SmartObject in a view, and the view does not contain the value yet, it can be faster to call the SmartObject method directly from the form rather than calling a form event to retrieve the SmartObject property. In these cases, use the Execute a SmartObject method action rather than the Execute a View method action||Video: SmartObject Methods vs. View Methods|
|Limit the number of properties returned by a SmartObject used in a drop down list||When you use a SmartObject to populate a drop-down list, all the properties of the SmartObject list method are passed to the view, even if you only need one or two properties of that SmartObject in the drop-down list. You can improve performance by creating a new method for the same SmartObject which only returns the properties you need in the drop-down list.||Video: Improving performance by limiting SmartObject data|
|Keep the number of form States for a form to a minimum||Whenever you define a new form state, all the rules for the forms are duplicated for the new state. Try to limit form states to only those states that are necessary, or re-use states where possible. When the form states differ significantly, it may be easier to define a separate form than try to handle all possible scenarios in one form definition|
|Use lookup/picker controls instead of drop-down lists for large data sets||If you are populating a drop-down list with a large dataset (50 records or more), it is better to use the Lookup control rather than a drop-down list. If you MUST use a drop-down list, try to populate the drop-down list asynchronously. Where possible.|
|Refactor, clean and simplify form and view rules||Cleaning up form rules and view rules can speed up development and runtime experience. Remove unused rules and try to simplify the actions and conditions as much as possible. Before publishing your form/view, refactor and remove any unused rules and actions from the form/view. This is especially true for rules used only during development or debugging, since they add unnecessary bloat to a form.|
|Limit rules and actions to only what’s necessary||Avoid performing unnecessary rules/actions on a form or view. For example, it is not always necessary to re-initialize a view. Clearing a view's controls can clean the view for input without needing to re-populate the drop-down items on the view, for example. Another example: when you add a view to a form, the form initialize rule is automatically updated to include an action which executes the view’s Initialize rule, even if the view doesn’t have an Initialize rule defined. Make sure that Initialize rules are executed only for the views that have Initialize rules defined.|
|Remove hidden fields that were only used for development/debugging purposes||Hidden fields that are not used just add overhead to a view/form. Remove any hidden fields that were only used for development or troubleshooting purposes. Exception: hidden fields can help to simplify form/view design, so sometimes you will use hidden fields to improve or simplify runtime execution.|
|Define separate views for List views in read-only and edit mode||If you need to re-use the same List view in both Read-Only and Edit modes on different forms, it may be worthwhile to define separate List "Edit-mode" and List "Read-Only" mode views for the List view. Adding complicated rules to enable/disable editing conditionally on a list view with many expressions/rules and validations can impact runtime performance and complicate development.|
|Load data only when necessary||Wherever possible, try to load data only when it is required. For example, do not unnecessarily populate drop-down lists on hidden tabs, or do not unnecessarily populate a list view on initialize if the List view will be populated by a subsequent action anyway. When using tabs, populate the first tab in one execution block and then populate the remaining tabs in separate execution blocks. Where possible, delay the population of the other tabs/views until they are actually needed. You can use certain events or rules to delay populating a form/view with data until the user explicitly asks for that data, and remember to use the various execution Types (e.g. sequential, concurrent or batch) to populate data in the most efficient way.||Video: Using Tab events to load data on-demand|
Video: Using View events to load data on-demand
|Combine Data Transfer actions where possible||Populating controls with values using the Data Transfer action is currently a client-side operation. Try to limit the number of individual Transfer data actions and wherever possible. Combine data transfer so that multiple controls/fields are populated in the same Transfer Data action.|
|Use associations sparingly||Discovering associations between SmartObjects can add overhead. For example, while a view can discover an association for the current SmartObject and automatically generate a drop-down list for you, it may be more efficient at runtime if you remove the association and create the drop-down list manually, pointing it to the relevant SmartObject. This way, you remove the additional overhead added by the association.|
|Use the Execute another rule action to call the same rule definition from different events. ||If you have rules that are used multiple times from different events, or a sequence of actions that you would like to define as a re-usable 'chunk' of actions, you can define 'event-less' rules with the actions to execute, and then call the event-less rule from another event with the Execute another rule action. |
This approach allows you to define a re-usable set of actions once, and re-use the same sequence of actions in different places. It can also reduce the size of the form definition sent to the client and improve runtime performance.
|For complex IF…ELSE conditions in a rule, base the rule execution on the value of a hidden control||If you have complex IF..ELSE evaluations in a rule, it can be easier to base the IF..ELSE condition on a single hidden control's value, rather than handling all the conditions inside a rule definition. Use "Data Transfer" actions in the IF parts to set the value of the hidden control.||Video: Advanced conditional statements in SmartForm Rules|