OnActuate is committed to ensuring our customers understand the products and services they are investing in. Check the OnActuate blog every quarter to learn about the important updates to the cloud and more.
Update in March 2023
Platform Version: 10.0.32
Build Number: 10.0.1549
Link: March Update 2023
Build forms that fully utilize saved views.
New extension methods to improve the handling of default queries with saved views
The Saved views feature can be an extremely useful way for users or organizations to optimize the user experience. Data indicates that this feature is currently used primarily to save queries on list pages, so that users can quickly return to specific datasets either on page load (when the view is made the default view) or on demand. Feedback from the community has indicated that the use of views on list pages is impeded in some scenarios because of the default handling of the view’s query in relation to the form’s query. Typically, because of this default handling, the default view’s query isn’t loaded, and the user receives a warning or error message. To address the most reported customer concerns and enable users to use views as they expect in more situations, two new extension mechanisms have been added to give form developers more control over the query that’s run when a page or view is loaded.
Custom Filters
Custom filters are controls that are modelled on forms and that cause modifications to the query. Users will have a suboptimal user experience if the integration between views and these custom filters isn’t implemented. For example, the views might not be marked as having unsaved changes after a custom filter is used, or the custom filter value might not always be aligned to the current view or query.
Methods were introduced specifically to improve custom filter support with saved views.
- public void queryFiltersChanged(): This new method is called when the query is rerun by the system after changes to the query (for example, when a view loads or a system filtering mechanism is used). Therefore, the custom filter control has an opportunity to interrogate the mostly recently run query to find any relevant filter and update its value so that it appropriately reflects that query.
- element.formCustomFilterChanged(): This new API is called by the custom filter control when it has changed the query on the user’s behalf. When it’s called, the system marks the view definition as having unsaved changes. The recommendation is to call this API at the end of the control’s modified() method if changes to the control immediately cause the query to be refreshed, or to call this API for a custom filter on a button click if the adjustment of one or more custom filters requires a button for the changes to take effect.
Giving the default view property over a menu item query
By default, if a user navigates to a page by using a menu item that has an associated query, the system will run the menu item’s query instead of the default view’s query. In this case, the user is notified by an informational message that includes an action to force load the default view’s query.
In version 10.0.32, a new extension point has been added to enable form developers to override this default system behaviour for individual forms. Specifically, developers can call the EnableSavedViewQueryPriority method from the FormRunPersonalizationSettings class before super() of init() during the form lifecycle to give the default view’s query priority over the menu item’s query.
When this behaviour is enabled, the system will try to merge the default view’s query with the menu item’s query during the run() portion of the lifecycle.
Improving form load performance
Traditionally, personalization’s have been applied during the super() of run(), after the form query has been initially run. Because of this timing, if personalization’s included an added field, the query might be rerun to ensure that the extra data was fetched. With saved views, personalization’s that are related to the default view were applied at the same time as before. However, the possibility of at least one extra execution of the query during form load increased, because an extra execution occurred if the default view contained any personalization’s that affected the query. These personalization’s include added fields, modified filters, and modified sorting.
As of version 10.0.29, you can use the Saved views performance enhancement feature to help improve the performance of form load for default views that contain personalization’s that affect the query. This feature changes when some parts of the default view are applied, so that all query-related changes (such as added fields, modified filters, and modified sorting) are in place when the form initially runs its query in super() of run(). Therefore, the system runs the form query only once during form load, instead of potentially multiple times. In this way, the feature can speed up the load time for forms.
However, because this feature changes when some personalization’s that are associated with the default view are applied, the behaviour on the page might change. Any code that affects the query in the OnPostRun event handler of the form will now be run after the view query is run, not before. Therefore, before you enable the feature, you should evaluate any query-affecting code in the OnPostRun event handler in forms.
If you have any questions or concerns about the latest capabilities, or require assistance on your digital transformation, contact OnActuate!
Read the previous update here.
