This is the fifth article in a series provided for non-technical System Administrators who wish to understand more about using JavaScript to control workflow and to implement simple customizations using the language.

In this article, I will start to explain the different types of JavaScript data types and how we use them in Sage CRM scripts. As part of that, we will look at the Browser Document Object Model and how objects are referenced and controlled in Client Side Coding.

In the previous articles, I discussed that different objects are available to our scripts depending on where the code is executed.

I want to turn now to consider the objects that are available within the Browser. The way in which a browser processes the HTML of a page and the need to allow a script to interact with the HTML structures means that the scripting engine needs to have a conceptual model of the different tags that together make up the page.

This is called the Browser Document Object Model.

The Document Object Model is a programming API for the HTML documents. It is based on an object structure that closely resembles the structure of the documents it describes.

HTML documents have a logical structure which can be imagined as being like a tree; or rather a collection or "forest" of trees because a document can contain more than one tree.

We use the term Document Object Moded to describe this tree-like representation of a document. We also use the term "tree" when referring to the arrangement of those information items which can be reached by using "tree-walking" methods.

When we open something like an Opportunity Summary page in Sage CRM then in the browser we will have a document that will have a form that contains fields of type text or hidden or select. And the same document will have hyperlinks and other tags that can be accessed and controlled using JavaScript.

The example above is a simple onChange script within the definition of a workflow rule. This uses the key word ‘this’ to check the properties of the current object within focus – which in this case happens to be the field oppo_certainty itself.

The business rule checks whether the certainty has been set higher than the value allowed at this point within the workflow process.

In the interface, this result in a message displayed on the screen when the conditions are breached.

And the value is automatically corrected to the maximum value allowed.

This is the code I used.

The way in which an onChange script works is that when the field content changes then the event fires.

Your code can only access Browser Objects but you have Full access to the DOM (Document Object Model) and the object-specific properties – the ‘value’ of the field for example.

And we can use any other objects and functions that exist in the browser, that includes custom libraries of objects – the ‘crm’ object is one such custom object that forms part of the Sage CRM client-side API.

I want to keep these articles short so I will end here.

I have used here the example of a script that is triggered when a field is changed in the browser. This change is an 'event'. In the next article, I will develop the idea of binding a script to an event like loading a document/page into the browser.