Managing Client Side Code in Sage CRM (for Sage CRM v7.1sp2 and earlier)

Hints, Tips and Tricks

Technical Hints Tips and Tricks that cover customization and development using Sage CRM. API usage and coding are covered.

Managing Client Side Code in Sage CRM (for Sage CRM v7.1sp2 and earlier)

  • Comments 6
  • Likes

Note:  This article discusses techniques relevant for Sage CRM v7.1 and earlier.  If you are using Sage CRM 7.2sp2 please refer to the articles that discuss the new Client Side API.

How do we manage our client side script in Sage CRM to maximise our ability to maintain the code ?

For those new to Client side scripting in Sage CRM generally the code is added into the Custom Content and On Change Script multi line text fields in Administration | Customisation |Screens.

 

These fields are just multi line text fields that are stored in the Sage CRM database.

The content of the Custom Content field is stored in the Custom_ScreenObjects table in an nText field called CObj_customContent

 

The content of the On Change Script field is stored in the Custom_Screens table in an nText field called seap_onChangeScript.

 


On large customised sites, or sites where the developer has moved on, it can become a nightmare to find all the client side code and what it was supposed to do - especially if there is no documentation. .Just hunting down the code in the Sage CRM interface can be a time consuming task . This is because there can be an onChange Script for each field on the screen,  so you need to open the Screen in Administration | Customisation | Screens and then click or tab through each field in the screen contents to find all of the On Change Script code. As the content is stored in the database it could potentially be made available to report on or create a custom component to present it in a different way - there are 3rd party applications available to assist with this when needed. Either way you look at it there is additional time and cost implications to these approaches.  

The other issue with having this data stored directly in the tables that is used to build the screens by the eWare.dll is that it eliminates the ability for any form of version control to be done directly into the database on these particular fields without some changes made to the fundamental architecture in Sage CRM.

Here are some suggestions to eliminate the above frustrations

1. Do not use the On Change Script field - Add everything to the Custom Content

I know it sounds radical but the onchange event is just 1 of the many events available for you to interact with in the DOM.  To interact with these other events ((onload, Propertychange, Focus, Blur etc) we write it into the CustomContent. There is a little more work involved but the great news is all the code is in one place. Here is an example of moving an onchange script to the custom content. We do this in 3 steps

  • Write the stuff you want to happen on change of an element into a function (This would be the comp_nameOnChange function in the example below.
  • Find the element and the event you want to attach this function to and write this into a function (this would be the attachOnChange function in the example below)
  • Finally we need to wait until all the elements on the page have been rendered by the browser before we run the function above. We do this by using window.setTimeout to run the function once after a number of milliseconds have passed after the page is fully rendered.

<script>

function comp_nameOnChange()
{
alert('I Changed');
}

function attachOnChange()
{
objCompName = document.getElementById('comp_name');
if(window.attachEvent)
                objCompName.attachEvent('onchange',comp_nameOnChange);
else
                objCompName.addEventListener("change",comp_nameOnChange,true);
}

window.setTimeout('attachOnChange()', 100);

</script>

2. Move the contents of your Custom Content into a file

The idea here is that if we put the code in a file we can access it via an IDE e.g. Visual Studio Developer Edition. We can also then apply version control to these files.

  • Create a folder on the server under custom pages called ClientSideScript.
  • Create a file using a consistent naming convention for example the name of the screen the js relates to. E.g. CaseDetailScreen.js
  • Copy the content of the Custom Content field to this file (without the script tags)
  • Replace the contents of the Custom Content field with a Script tag to Custom Content to download the code file as a resource to the web page. E.g.

<script src="../custompages/cscasesearchscreen.js" type="text/javascript"></script>

NOTE: The Script tags that are placed in the custom content are positioned relative to the resource that is calling them for instance

  • if the screen was being called by the eWare.dll

<script src="../ClientSideScripts/cscasesearchscreen.js" type="text/javascript"></script>

  • if the screen is being referenced from an ASP page

<script src="/ClientSideScripts/cscasesearchscreen.js" type="text/javascript"></script>

  • You could also bypass the Custom Content area and add it directly to your ASP page that is stored in CustomPages/Projects/ProjectEdit.asp

<script src="../ClientSideScripts/cscasesearchscreen.js" type="text/javascript"></script>

3. Use JQuery to simplify your code. The example in point 1 could be written in JQuery using the following code.

$('#comp_name').on('change', function(event){alert('I Changed');})

That's right 1 line of code - supporting multiple browsers.

4. Use an IDE for Development

Now the JavaScript and JQuery is stored in files rather than in the database we can use an IDE to develop with, as an example Visual Studio 2010 Developer Edition.

 

The code is now clearly identifiable and readable within an IDE. There is Native support for Javascript and JQuery in Visual Studio 2010 Developer Edition.

5. Use Version Control against the files 

As the code is now stored directly in the file system standard Version Control methods can be used with the code.

 

Comments
  • Great blog Kaan, and definitely good advice.  Just an early FYI to those who are considering moving their code to files -  In Sage CRM 7.2 we are going to create a "global client side script library entry point".  This will allow you to store your own client side libraries in version controlled .js files that are automatically picked up and made available across all Sage CRM screens.  This should facilitate quicker, portable customization, the sharing of code, and possibly the creation of a common functions library provided out of the box.  While 7.2 is not being released for some time, following Kaan's advice NOW will make transitioning to the new model easier in the future.

  • Hi Sean, that is fantastic. Looking forward to 7.2!

  • I know that skill, but be carefull about the Cache。 sometime, when you upgrade the code, the customer's Browser will not update the new js files.  you can do it like that :

    <script src="../custompages/cscasesearchscreen.js?v=20120528" type="text/javascript"></script>

    when you upgrade ,change the parameter.

  • Hey Bill, Great tip thanks for sharing.

  • Thanks, great stuff.  I finally implemented most of your ideas and can't believe I waited so long!

  • Fantastic, it is great to hear it is being put to good use. Sage CRM has come along way with the 7.2 release in simplifying the deployment of client side Javascript library's with the new JS folder and simplifing client side development with the release of the client side API, looking forward to see how this is used and developed by the community over the coming year!