Neudesic Blogs

Passion for Innovation

Slickgrid Currency Column Formatter


Slickgrid is a JavaScript grid component by Michael Leibman.  This is a great grid which is very flexible and customizable and very fast to load and display data.  Over the next few weeks we will be blogging about Slickgrid in general as well as a few areas in which we have extended its functionality.  This blog will address one of those areas where functionality was extended.


I recently came across the need to display pricing information for products and could not find information on a currency column formatter.  The raw data returned from my web service displayed the data as 0.0000.  So there was no currency formatting ($ symbol) and the decimal precision was returned to four places.  I wanted the data to be formatted like typical US currency with a $ and to two decimal places, like this: $0.00.  Maybe I didn't look hard enough to find a ready-made solution, but at any rate, I quickly wrote my own currency formatter and thought it might help someone else looking to do something similar.


The column formatting functions for Slickgrid are contained in the slick.formatters.js file.  I appended this file with a new function by adding the following bit of code:


function CurrencyFormatter(row, cell, value, columnDef, dataContext) {

    if (value === null || value === "" || !(value > 0)) {

        return "$" + Number();

    } else {

        return "$" + Number(value).toFixed(2);




Additionally, you will need to modify the top section of the script to register the newly created namespace.  I added the following code (highlighted in yellow) to the existing function:


(function ($) {

  // register namespace

  $.extend(true, window, {

    "Slick": {

      "Formatters": {

        "PercentComplete": PercentCompleteFormatter,

        "PercentCompleteBar": PercentCompleteBarFormatter,

        "YesNo": YesNoFormatter,

        "Checkmark": CheckmarkFormatter,

        "Currency": CurrencyFormatter





Now when you define your columns in your html page that will display your Slickgrid control, you need to add the following bit of code to the column definition to reference the currency formatting function that we just created above:


                columns = [

                { id: "Price", name: "Price", field: "Price", width: 80, cssClass: "cell-title", formatter: Slick.Formatters.Currency }



That's it.  Now the data shown in the currency formatted column will display as "$0.00", rather than the raw, unformatted data that may be returned in your web service or database call.  If the value being evaluated is null, an empty string or an empty object, the data will be rendered as $0.  This did the trick for me!  Stay tuned for more Slickgrid information in future blogs.  Happy coding.

Tidy up your JavaScript (CRM JScript)


Ah, JavaScript...we all love to hate it. But the fact is that JavaScript is one of the most popular programming languages in the world and its widespread use will continue to grow with the increased use of popular JavaScript libraries like jQuery. It is the language of the web. JScript, Microsoft's implementation (really just a different name) of JavaScript, is an integral part of developing and extending the capabilities of MS CRM. CRM 2011 is particularly geared toward the extended use of JavaScript with the inclusion of web resources and the REST endpoint/Odata web service architecture. The recommended (and provided SDK samples) interaction with the new REST endpoint is with the jQuery library and using JSON formatted data, both of which are JavaScript based.


Given this popular and ever growing use, there are a few (many actually) things that should be taken into consideration when writing JavaScript code. Douglas Crockford provides an extensive and in-depth discussion of these items in his book "JavaScript: The Good Parts". I would highly recommend this book for anyone who works with JavaScript frequently. One of my favorite quotes from the book is this:  


"The amazing thing about JavaScript is that it is possible to get work done with it

without knowing much about the language, or even knowing much about programming." 


But this ease of use doesn't necessarily mean that the code will be consistently reliable or will be using best practices. This is very true with its use in MS CRM...there is plenty of information available on the web and just about anyone can copy-n-paste a code snippet or two and bam you are programming! But there are risks with proceeding this way, as there are many code samples out there that may not be written with best practices in mind. To help mitigate this risk, I would like to discuss a couple easy items that can help clean up your JavaScript and may save time troubleshooting and tracking down mysterious issues.  


Here's a couple key points that I'd like to talk about to get you started with better JavaScript code: 



  • Declaring variables, not using the var keyword

Common practice (at least sometimes):

  • myVariable = "Jerry";


Best practice:

  • var myVariable = "Jerry";


Why: JavaScript lets you use a variable even when you have not explicitly declared it.  However, this makes the variable a global variable, which means that it is accessible to the program outside of the scope in which it is being used.  This can easily lead to naming conflicts and unintentional reassignment of a variable's value.  Bottom line: always declare variables with the var keyword.


  • Placement of curly braces {}:


Common formatting, especially for C# users, is to format a statement like so: 

If (test)


//code here


Best practice:

If (test) {

//code here


Why: JavaScript will try to automatically correct and insert semicolons where it thinks they belong. In certain situations, this can yield incorrect results, like when trying to set an object's value and it is inadvertently turned into a statement when a semicolon is automatically added. 


  • Testing for equality and inequality

Common practice:

  • == to test for equality
  • != to test for inequality


Best Practice:

  • === to test for equality
  • !== to test for inequality


Why: When testing for equality or inequality, if the operands (the objects being compared) are of a different type, then == may yield incorrect results in certain instances. For example, ' ' == 0, will return true, when in fact it should be false. The === will correctly return false. Bottom line: use === and !== instead of == and !=. 


Yeah, I can hear it now…"these things are so uncommon that they're not even worth talking about". But, like constructing a good building, its better to start with a strong foundation than to continue building upon minor mistakes, which over time may cause it to collapse. And furthermore, if the JavaScript guru Crockford says it’s a good idea, well, then I will faithfully follow in pursuit! Happy coding.

Posted: Feb 17 2012, 05:53 by Jerry.Fetzer | Comments (0) RSS comment feed

Categories: Dynamics CRM

About Jerry Fetzer

RSS Feed





Neudesic Social Media

Follow Neudesic on Twitter Follow Neudesic on Facebook Neudesic Neudesic