Client-side scripting design and processing
-
- UpdatedAug 1, 2024
- 9 minutes to read
- Xanadu
- Building applications
Well-designed client scripts can reduce the amount of time it takes users to complete a form.
Proper client-side processing depends on the form loading first. Making record updates prior to form load can produce unexpected results that bypass client-side processing.
- Disable list editing for the table.
- Create appropriate business rules or access controls for list editing.
- Create data policies.
- Create a separate onCellEdit client script.
Restrict list editing
If you create UI policies or client scripts for fields on a form, you must use another method to ensure that data in those fields is similarly controlled in a list.
- Disable list editing for the table.
- Create appropriate business rules or access controls for list editing.
- Create data policies.
- Create a separate onCellEdit client script.
Minimize server lookups
Use client data as much as possible to eliminate the need for time-consuming server lookups.
Client scripting uses either data available on the client or data retrieved from the server. The top ways to get information from the server are g_scratchpad and asynchronous GlideAjax lookup.
The primary difference between these methods is that g_scratchpad is sent once when a form is loaded (information is pushed from the server to the client), whereas GlideAjax is dynamically triggered when the client requests information from the server.
Example: Retrieve server data using g_scratchpad
The g_scratchpad object passes information from the server to the client, such as when the client requires information not available on the form.For example, if you have a client script that needs to access the field u_retrieve, and the field is not on the form, the data is not available to the client script. A typical solution to this situation is to place the field on the form and then always hide it with a client script or UI policy. While this solution may be faster to configure, it is slower to execute.
If you know what information the client needs from the server before the form is loaded, a display business rule can create g_scratchpad properties to hold this information. Theg_scratchpad is sent to the client when the form is requested, making it available to all client-side scripting methods. This is a very efficient means of sending information from the server to the client. However, you can only load data this way when the form is loaded. The business rule cannot be triggered dynamically. In those cases, use an asynchronous GlideAjax call.
- The value of the system property css.base.color
- Whether or not the current record has attachments
- The name of the caller's manager
Example: Retrieve server data using asynchronous GlideAjax
Asynchronous GlideAjax allows you to dynamically request information from the server.
Use the setValue() displayValue parameter for reference fields
When using setValue() on a reference field, include the displayValue parameter to avoid additional server calls.
When using setValue() on a reference field, be sure to include the reference field display value as the 3rd parameter. If you set the value without the displayValue, the instance does a synchronous call to retrieve the display value for the record you specified. This extra round trip to the server can impact performance.
Example
Example
Use UI policy instead of a client script
When possible, consider using a UI policy instead of a client script.
- UI policies have an Order field to allow full control over the order in which client-side operations take place.
- UI policies do not require scripting to make a field mandatory, read-only, or visible.
Validating the input by using a client script
An excellent use for a client script is to validate the input from the user.
This validation improves the user experience because the user finds out if there are data issues before submitting the information.
Example
Set client script order
Control the order of execution for your client scripts using the Order field. To avoid having two or more client scripts run concurrently and then conflict, you can add an order for the scripts to run in.
Before you begin
About this task
Procedure
Avoid DOM manipulation
Avoid Document Object Model (DOM) manipulation if possible. It can cause a maintainability issue when browsers are updated.
Instead, use the GlideForm API or consider a different approach for the solution. In general, when using DOM manipulation methods, you have to reference an element in the DOM by ID or using a CSS selector. When referencing out-of-box DOM elements, there is a risk that the element ID or placement within the DOM could change, causing the code to stop working and/or generate errors. Use forethought, caution, and have a full understanding of the risk you are incurring. Review these objects and reduce the use of DOM manipulation methods as much as possible.
Avoid global client scripts
A global client script is any client script where the selected Table is Global. Global client scripts have no table restrictions, therefore they will load on every page in the system introducing browser load delay in the process.
There is no benefit to loading this kind of scripts on every page.
As an alternative, and for a more modular and scalable approach, consider moving client scripts to a base table (such as Task[task] or Configuration Item[cmdb_ci]) that can be derived for all the child/extending tables. This eliminates the system loading the scripts on every form in the UI - such as home pages or Service Catalog where they are rarely (if ever) needed.
Enclose code in functions
Enclose the code in a client script inside a function.
Client scripts without a function cause issues with variable scope. When code is not enclosed in a function, variables and other objects are available and shared to all other client-side scripts. If you are using the same variable names, it is possible that they could collide. This can lead to unexpected consequences that are difficult to troubleshoot.
This solution is much safer because the scope of the variable state is limited to the onSubmit() function. Therefore, the state variable does not conflict with state variables in other client-side scripts.
Run only necessary scripts
To avoid running time-consuming scripts unnecessarily, make sure that client scripts perform only necessary tasks.
The following examples demonstrate improvements to the initial code sample. Each example demonstrates a particular enhancement to the script to improve performance and avoid unnecessary calls.
Example
Remember that client scripts have no Condition field. This means that onLoad() and onChange() scripts run in their entirety every time the appropriate form is loaded. This example is an inefficient onChange() client script set to run when the Configuration item field changes.
Example
This example improves upon the first by replacing the getReference() or GlideRecord lookup with an asynchronous GlideAjax call.
Example
The isLoading flag is the simplest way to prevent unnecessary code from taking up browser time in onChange scripts. The isLoading flag should be used at the beginning of any script that is not required to run when the form is loading. There is no need to run this script on a form load because the logic would have already run when the field was last changed. Adding the isLoading check to the script prevents it from doing a cmdb_ci lookup on every form load.
The isTemplate flag indicates that a template is loading.
Example
Example
Example
On this page
- Restrict list editing
- Minimize server lookups
- Use the setValue() displayValue parameter for reference fields
- Use UI policy instead of a client script
- Validating the input by using a client script
- Set client script order
- Avoid DOM manipulation
- Avoid global client scripts
- Enclose code in functions
- Run only necessary scripts