Client-side Scripting

Question 1

The following are examples of when to use what?

• Place the cursor in a form field on form load
• Generate alerts, confirmations, and messages
• Populate a form field in response to another fields value
• Highlight a form field
• Validate form data
• Modify choice list options
• Hide/Show fields or sections

Answer 1

Client side scripts (execute within a user’s browser and are used to manage forms and fields)

Question 2

When should an onLoad client script be used?

Answer 2

Use onLoad Client Scripts to manipulate a form’s appearance or content. For example, setting field or form-level messages based on the presence of a value. Use onLoad Client Scripts sparingly as they impact form load times.

Question 3

When should an onChange client script be used?

Answer 3

onChange Client Scripts execute script logic when a particular field’s value changes. Use onChange Client Scripts to respond to field values of interest and to modify another field’s value or attributes. For example, if the State field’s value changes to Closed Complete, generate an alert and make the Description field mandatory.

Question 4

When should an onSubmit client script be used?

Answer 4

onSubmit Client Scripts execute script logic when a form is submitted. Use onSubmit Client Scripts to validate field values. For example, if a user submits a Priority 1 record, the script can generate a confirmation dialog notifying the user that the executive staff are copied on all Priority 1 requests.

Question 5

What is the “onCellEdit” type of client script?

Answer 5

This is a fourth type of script that is used for lists rather than forms

Question 6

What is the “Inherited” checkbox used for?

Answer 6

This determines if a script will apply to child tables. For example a client script on task table would also be inerited by the change, incident, problem table, etc.

Question 7

Which type of client script(s) do/does not have any arguments passed in by default?

Answer 7

onLoad and onSubmit do not have any arguments passed in

Question 8

Which type of client script(s) has/have arguments passed into them and what are those arguments?

Answer 8

onChange client scripts have the following arguments passed in:

• control
  
  • field the Client Script is configured for
• oldValue
  
  • value of the field when the form loaded and prior to the change
• newValue
  
  • value of the field after the change
• isLoading
  
  • boolean value indicating whether the change is occurring as part of a form load. Value is true if change is due to a form load. When forms load, all the field values on the form change as the record is loaded into the form
• isTemplate
  
  • boolean value indicating whether the change occurred due to population of the field by a template. Value is true if change is due to population from a template

Question 9

how does “oldValue” work on an onChange client script?

Answer 9

The oldValue is set from the database when the form loads and will not change until the next time the form loads no matter how many times it is changed in between or what client scripts change the value of the field in question

Question 10

What is GlideForm?

Answer 10

The GlideForm API provides methods to customize forms.

GlideForm.js is the JavaScript class containing the methods. The global object g_form is used to access GlideForm methods. GlideForm methods are only used on the client. These methods are used to make custom changes to the form view of records.

Question 11

Where can GlideForm methods be accessed and what is the appropriate syntax to do so?

Answer 11

Available only on the client side.

Accessed using the method:

g_form.

example:

alert(g_form.getValue(‘short_description’));

Question 12

What is the GlideUser API?

What methods are available to the GlideUser API

Answer 12

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.

• Retrieve the user’s:
  
  • First name
  • Full name
  • Last name
  • User ID
  • User name
• Determine if a user has a particular role assigned

Question 13

Where is g_user API available?

Answer 13

Client Scripts only!

Question 14

what do the following scripts do:

g_user.hasRole(‘client_script_admin’);

g_user.hasRoleExactly(‘client_script_admin’);

Answer 14

The first script will return a value of true if the current user has the role listed or any role that contains that role (such as admin)

The second script will return a value of true if the current user has the exact role mentioned in the script (inherited roles still return false)

Question 15

What are UI policies, how do they differ from client scripts?

Answer 15

they are client-side logic that governs form and form field behavior.

Unlike Client Scripts, UI policies do not always require scripting

Question 16

For UI Policies what must be selected for the “Execute if false” script to run?

Answer 16

“Reverse if false” checkbox

Question 17

Answer the following for Client Scripts and UI Policies:

Executes on form load

Execute on form save/submit/update

Execute on form field value change

Has access to field’s old value

Executes after Client Scripts

Set field attributes without scripting

Requires control over order of execution

Answer 17

Client Scripts:

• Executes on form load - Yes
• Execute on form save/submit/update - Yes
• Execute on form field value change - Yes
• Has access to field’s old value - Yes
• Executes after Client Scripts - No
• Set field attributes without scripting - No
• Requires control over order of execution - Yes

UI Policy:

• Executes on form load - Yes
• Execute on form save/submit/update - No
• Execute on form field value change - Yes
• Has access to field’s old value - No
• Executes after Client Scripts - Yes
• Set field attributes without scripting - Yes
• Requires control over order of execution - Yes

UI policies run last so will overwrite client scripts. Client scripts have access to the order field but it is not on the view by default

Question 18

Which of these classes are part of the ServiceNow client-side API?

1. GlideSystem (gs)
2. GlideUser(g_user)
3. GlideDateTime
4. GlideDate
5. GlideForm(g_form)

Answer 18

ANSWER: Responses 2 and 5 are correct. GlideUser and GlideForm are part of the ServiceNow client-side API. If you are not sure whether a class is part of the client-side or server-side API, check the API Reference.

https://developer.servicenow.com/app.do#!/api_doc?v=sandiego&id=client

Question 19

When do onSubmit Client Scripts execute their script logic?

1. When a user clicks the “Submit” button
2. When a user clicks the “Delete” button
3. When a user clicks the “Update” button
4. When a user clicks the “Save” menu item in the “Additional Actions” menu
5. When a user clicks the “Lookup” button on a reference field

Answer 19

ANSWER: The correct responses are 1, 3, and 4. onSubmit Client Scripts execute their script logic whenever a user saves, submits, or updates a record in a form.

Question 20

True or False? A single Client Script can execute its script logic when a user loads a record into a form AND when a user saves/submits/updates a form.

Answer 20

False. A single Client Script can be either onLoad OR onSubmit but cannot be both. The Type field determines whether a Client Script is an onLoad or an onSubmit Client Script.

Question 21

True or False? A single Client Script can execute its script logic when a user loads a record into a form AND when a user changes a value in a field.

Answer 21

True:

This question is a little tricky. You must examine the Client Script trigger configuration as well as the onChange Client Script script template. When the Client Script Type field value is onChange, the script template includes logic to check whether the field value changed due to a form load. When a form loads a record from the database, all field values on the form change from no value to the values in the record being loaded from the database. The default client script logic returns (does not execute the remaining script logic) if the isLoading value is true. The isLoading value is true if the field value changed due to a form load.

To execute an onChange Client Script’s logic when a form loads, remove the isLoading check from the onChange script template.

Question 22

QUESTION: Examine the onChange Client Script script for the Urgency field:

function onChange(control, oldValue, newValue, isLoading, isTemplate) {

// Default template returns if the value change was caused by a form load

if(isLoading || newValue === ‘’){

return;

}

alert(“The urgency for this Incident record changed to: “ + g_form.getValue(‘urgency’));

}

If a user changes the value in the Urgency field to 1 - High, what text will appear in the alert?

The urgency for this Incident record changed to: 1 - High

The urgency for this Incident record changed to: High

The urgency for this Incident record changed to: 1

The urgency for this Incident record changed to: a different value

There will be no alert

Answer 22

The correct response is response 3.

Scripts use choice field Values and not field Labels. Form fields use Labels for choice fields.

Question 23

True or False? UI Policies require scripting to make form fields Mandatory, Visible, or Read only.

Answer 23

False. Use UI Policy Actions to set field attributes without scripting.

Question 24

When can UI Policies execute their logic? More than one response may be correct.

1. When a record is loaded into a form
2. When field values change on a form
3. When a form is saved, submitted, or updated
4. When a Client Script executes
5. When a record is loaded into a list

Answer 24

1 and 2. The On load option determines whether a UI Policy executes its logic when a record is loaded into a form. UI Policy logic also executes whenever the Conditions field evaluates to true.

Question 25

Which of the following is a strategy for debugging Client Scripts or UI Policies? More than one response may be correct.

1. Browser’s Developer Console
2. Debug UI Policies module
3. JavaScript try/catch
4. JavaScript Log and jslog()
5. Field Watcher

Answer 25

All of the responses are debugging strategies for client-side script logic.

Question 26

Do UI Policies execute UI Policy scripts only when the Condition field evaluates to true? Explain your reasoning.

Answer 26

If the Reverse if false option is selected, UI Policies execute the Execute if false script when the Condition field evaluates to false.