I regularly use FireBug in Firefox my for my JavaScript debugging. Back in the mozilla days I would just enter javascript: in the address bar and get the nice dialogue that shows to tell me the location of the error. We can all agree we have come a long way. Now that Firebug is also in Chrome we have another tool. I admit I do not bother with JS debugging in IE much, but I have pressed F12 a few times in the app to get up the dev tools.

So to put it short I could not do as good of a job as the guys over at alistapart.com. Check out what they have to say about debugging in JS “after the jump”:

“When used effectively, JavaScript debuggers help find and squash errors in your JavaScript code. To become an advanced JavaScript debugger, you’ll need to know about the debuggers available to you, the typical JavaScript debugging workflow, and code requirements for effective debugging. In this article, we’ll discuss advanced debugging techniques for diagnosing and treating bugs using a sample web application.”

http://www.alistapart.com/articles/advanced-debugging-with-javascript/

It is possible to retrieve data from SalesLogix web client using client side code. We have performed this task with Named Queries and SData both using jQuery to GET the data for us. This is not the easiest way and sometimes it is not the most ideal.

We are usually must more familiar writing server side code AND in an ASCX we start on the server anyway, so why not get the data from the entity there or write SData code on the server to retrieve our data? It is probably going to be easier and more familiar for most of us.

The reason why is because we need the data on the client ultimately. At some point to do charts or something else cool with a JavaScript Library you will need to get the data to JavaScript (the client).

So we want to write server side code to get data using SData, entity model or ADO.NET and spool out JavaScript.

How?

This is the easy part.

Get your javascript into a string of some sort.

Something like:

string s = "function sendmessage() {alert('here');}"

then write the code to actually send the javascript to the browser with the rest of the out put:

        ClientScript.RegisterClientScriptBlock(this.GetType(),"Chart JS",s,true);

This will get your code on the client and ready to be used by any other JavaScript on the page.

Where does this get us?

Well it tells us that we can write ANY JavaScript from the server side. So in the case of Ext js charts we can use this code to write data in the form that is needed by the charts. Just loop and format it properly and you are all set!

We are discussing this now for our Master’s Series class on Client Side Code in February.

To really get some client side validation in our pages we need to be able to stop postback. We already looked at how to get JavaScript in our pages but that only gets us so far.

We can write some JavaScript that will validate a form element, but the form will still submit! How can we stop that from happening?

Use return

Placing the word Return in front of your JavaScript call will tell the client that you want to actually listen for what the JavaScript function returns and either continue or stop based on that result.

So we change:

OnClientClick="cmdSave_ClientClick();

to:

OnClientClick="return cmdSave_ClientClick();

And edit our function to actually return true or false:

If you return false your form will NOT post. The one problem with this code is that if you return true your form will not post either…

So you need to handle the post yourself. Use firebug and get the actual ID of the button control (or other control that SHOULD be posting):
ctl00$MainContent$ProductDetails$cmdSave it should have $ in it not _ …

And add the following code when you actually want the form to post:

Of course your criteria for true and false is likely to be more complex, but we can get there.

To get started with a JavaScript library I suggest downloading one and giving it a try.

Let’s take Ext js. Download it here:

http://www.extjs.com/products/extjs/download.php

Extract the files to your IIS server or open the folder in Visual Studio as an existing web application. Browse to examples->Chart->charts.htm and press play. You cannot just double click this file and open in a browser. Go head and try – the flash player does not allow it. So run that page by right clicking it in VS.NET and view in browser.

Cool charts huh?

How did that happen?

Check out the source of the page. Look at the header.

  <!-- GC -->
 	<!-- LIBS -->
 	<script type="text/javascript" src="../../adapter/ext/ext-base.js"></script>
 	<!-- ENDLIBS -->
 
    <script type="text/javascript" src="../../ext-all.js"></script>
 
    <script type="text/javascript" src="charts.js"></script>

You can see that the page pulls in ext-base.jd and ext-all.js as well as a chart.js.

Chart.js just contains the actual data for the chart and the markup as well:

Ext.chart.Chart.CHART_URL = '../../resources/charts.swf';

Ext.onReady(function(){

    var store = new Ext.data.JsonStore({
        fields:['name', 'visits', 'views'],
        data: [
            {name:'Jul 07', visits: 245000, views: 3000000},
            {name:'Aug 07', visits: 240000, views: 3500000},
            {name:'Sep 07', visits: 355000, views: 4000000},
            {name:'Oct 07', visits: 375000, views: 4200000},
            {name:'Nov 07', visits: 490000, views: 4500000},
            {name:'Dec 07', visits: 495000, views: 5800000},
            {name:'Jan 08', visits: 520000, views: 6000000},
            {name:'Feb 08', visits: 620000, views: 7500000}
        ]
    });

    // extra extra simple
    new Ext.Panel({
        title: 'ExtJS.com Visits Trend, 2007/2008 (No styling)',
        renderTo: 'container',
        width:500,
        height:300,
        layout:'fit',

        items: {
            xtype: 'linechart',
            store: store,
            xField: 'name',
            yField: 'visits',
			listeners: {
				itemclick: function(o){
					var rec = store.getAt(o.index);
					Ext.example.msg('Item Selected', 'You chose {0}.', rec.get('name'));
				}
			}
        }
    });

Complex stuff at first glance, but first look at the data and then match up the items with the extjs markup.

Edit the data. Change the datanames. play around with it a bit and break it.
As always be sure to attend the Client Side Coding Master’s Series class.

SalesLogix uses a few JavaScript Libraries by default in their product. Let’s talk about what a JavaScript Library is first.

A javascript library takes some of the more complex and mundane parts of writing JavaScript and makes them easier and faster for the developer. It will usually also take all of the cross platform code that you would have ended up writing and makes it “go away”.

Cross platform?

Yeah IE and FireFox have never really agreed on how JavaScript should be written. It is really the rendering engine used in each that differs, but overall FireFox is MORE compliant with standards and IE is less. This is becoming less and less true and with HTML 5 we all dream this will go away, but in the real world we still have users running IE 6.0! IE 6.0 is an evil browser for a JavaScript programmer.

So you end up writing code that checks for document.layers or document.all and writing your FireFox code in one and IE code in the other.

This is all (mostly) a thing of the past with the various JS libraries out there.

What Libraries are out there?

SalesLogix uses three main libraries:

1. jQuery
2. EXTjs
3. YUI

But there are many more out there.

The Developer, Admin, End User subscription page uses DOJO and Prototype is a very popular library as well.

Explore, try and see what you can do. It is VERY easy compared to years past, but still more complex than most code you write today.

Now that we know that we are working with JavaScript — how can we actually make use of it inside the SalesLogix Web Client?

onclientclick()

Most controls have an onclientclick or equivilant that you can take advantage of.

OnClientClick=”cmdSave_ClientClick();

is a simple example.

This is accessed through Application Architect here:

In the screenshot I show “anything(“sasd”)” because there is a known issue with this actually writing code for you. But that isn’t a big deal.

So it is that simple.

You end up with the following code at the bottom of your ascx page. Go look!

We are preparing for our Client Side Coding Master’s Series class in February. During this process we tend to talk to a lot of people about the class and get some insight into what is misunderstood and what needs to be explored in the class. I have had some interesting conversations inside and outside of Sage. This seems to be an area that can use some explanation.

What is client side code?

Client side code is anything that runs in the browser. We are talking about SalesLogix web here, so this is anything running on the users machine in the browser — usually IE or FireFox. In most cases client side code is JavaScript.

What is the big deal with Client Side Code?

Most of the “waiting” you do on any web page is for the server to process the code of the page. It can also be for data retrieval and for actually sending the data to your browser as well. With client side code you turn that code into something that can be run on the client (remember client means browser – Firefox or IE in most cases). This means that the server has less of a load and you generally do not need to wait for the data to go back to the server and then back to you (commonly referred to as “post back”) to see your changes.

How does AJAX fit in then?

AJAX is Asynchronous JavaScript and XML. So it fits in as client side code, but that particular use of the technology allows you to click a button for instance and see a result without the whole screen refreshing. This is done with HTTP (web) requests through JavaScript. The data passed back and forth is generally XML, but it honestly can be any format JSON is a good one too.

AJAX is a bit complex at this moment, so lets just say we will get there in the class (if you made it to the SData Master’s series class I used AJAX in my SDataJavaScriptExample a lot). We are worried about the basics here.

So what do I need to know?

JavaScript runs on the client.
The client is your browser.
JavaScript is generally faster than server side post backs.
It also provides a really clean interface and user experience.

What is Firebug?

Firebug is a free add-on for Mozilla FireFox. It can be installed from https://addons.mozilla.org/en-US/firefox/addon/1843. Once it is installed it is launched by clicking the little “bug” in the lower right corner of FireFox. The bug will turn Orange to indicate it is enabled. Here you can see it turned “off”:

Why Firebug?

What can FireBug do for you that will help with your development? The most obvious feature is that is allows you to inspect the HTML code. While in this mode you hover over items on the webpage you are viewing and the code the generated these User Interface items will be shown. This is helpful when trying to diagnose misplaced elements on a page or when looking for the Cascading Style Sheet class that a particular UI element implements.

You can edit the Cascading Style sheets inline. By clicking the CSS tab at the top of the firebug window you can actually edit the CSS and make changes. These changes will be immediately reflected in the browser window.

The NET option allows you to see how long each request took to perform and the details of that request. This allows you to see all POST, GET, and other NET request sent down the http pipeline. You can tell what is being passed and how long it is taking. What is really important to me right now is being able to see the request and response headers. This tells me the authentication method I am using for my SData work in JavaScript.

The script tab helps if you need to debug your JS code. You can step through your code by placing a breakpoint to the left of the line of code that you want to break on. You can step through the code using the menu options in the upper right of the firebug toolbar.

How have I found it to be most useful?

When working with ATOM result sets like those received from a GET to an SData feed Firebug allows you to look right into the resulting XML. This makes traversing the DOM a bit easier since you can see where you are at in the structure. In previous days we would alert or print the elements while looping which was time consuming to say the least.
Internet Explorer 8 ships with a set of developer tools as well which rival what we use firebug for nearly every day. I guess since the days of the javascript: console in Mozilla it was hard to not use FireFox when it comes to client side code. Perhaps I will take a look at the IE tools in a future post.