Server side scripting include:
- UI Actions
- Business Rules
- Script Includes
- Client Scripts
- UI Policies
- Data Policies
Client-side scripts execute within a user’s browser and are used to manage forms and form fields. Examples of things client-side scripts can do include:
Client Scripts can be written either by accessing client scripts from the configure option on the form header or from the application navigator.
The different types that are available are
- onLoad - The script is executed when the form is loaded
- onCellEdit - Runs the script when we try to change any cell from list view
- onChange - Runs the script when there is a change on specific field
- onSubmit - Runs the script when the form is submitted
Client Scripts can also be inherited on to other tables which extend to the table https://developer.servicenow.com/app.do#!/lp/servicenow_application_developer/app_store_learnv2_scripting_istanbul_exercise_test_client_script_types?v=istanbulon which we create the client script.
Onload and onSubmit doesnt have any parameters passed to it, but onChange has some parameters to it.
function onChange(control, oldValue, newValue, isLoading, isTemplate){
// This is mandatory to ensure that the script doesnt execute when the onChange is called on loading
if(isLoading || newValue == '')
return;
}
- control: The field for which the onChange is configured
- oldValue: Value saved in the DB. This doesnt change with the intermittent values entered.
- newValue: The value to which the user has changed to.
- isLoading: boolean value to indicate the onChange is called when the form loads.
- isTemplate: If the change is from a template.
GlideForm Class:
The GlideForm client-side API provides methods for managing form and form fields including methods to:
g_form.<method name>
To see all the method the API link is below
https://developer.servicenow.com/app.do#!/api_doc?v=istanbul&id=clientGlideUser Class:
The GlideUser API provides methods and non-method
properties for finding information about the currently logged in user
and their roles. The typical use cases are personalizing feedback to the
user and inspecting user roles. Note that client-side validation in any
web application is easily bypassed.
The GlideUser API has properties and methods to:
The GlideUser methods and non-method properties are
accessed through the global g_user object that is only available in
client-side scripts. To use methods and properties from the GlideUser
class use the syntax:
g_user.<method or property name>
The GlideUser API also has methods for determining if a user has a specific role. For example:
g_user.hasRole('client_script_admin');
2.
UI Policies:
Like Client Scripts, UI Policies are client-side logic which governs form and form field behavior. Unlike Client Scripts, UI Policies do not always require scripting.
UI Policy Actions are client-side logic in a UI Policy used to set three field attributes: