Squash Those Bugs – LANSA WAMs debugging techniques (Part Two of Five)

Uncategorized

javascriptDebugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is part two in a five part series of blog posts that will be highlighting a number of tools and techniques that will help you squash those bugs. If you missed part one, it can be found here. This installment helps you answer the question “Is my client code correct”.

Is my client code correct?

Often when building a web application, your LANSA code is just part of the picture. Many times JavaScript is used as a client side language to augment and make your HTML more interactive. JavaScript can allow the web page to react to the users mouse movements, it can real-time reach out to the server for more information without submitting back the full page (AJAX). It can even move objects around the screen and fade elements in and out. The problem is that JavaScript can be tricky to debug. I highly recommend using the jQuery framework when doing any JavaScript development as it simplifies the syntax, and the procedures.
There are a few techniques which I use to determine if my code is correct:

Display key data using dialog boxes

Ahhh…the humble alert(). JavaScript is shipped with a command to display a simple text message in a dialog box on the screen. This command can be placed anywhere inside your JavaScript code and as the JS interpreter is stepping through the JS code, if it hits your alert(), it will popup a message. This is flawless and works in every browser. It’s the fallback if other methods do not work. I use it to a) show what pieces of code are executed, and b) what data is held in my variables at that time.

The example below demonstrates the simplicity of showing the traveled program path and the values at each stage.
[code]
var myField = ‘abcdef’;

alert(‘hello world’);

alert(‘start of program – value:’ + myField);

if (myField == ‘qqqq’) {
alert(‘inside first if statement – value:’ + myField);
}

myField = myField + ‘x’;
alert(‘after first if statement – value:’ + myField);
[/code]

alert
Tip: Be careful to remember to remove all these alerts() from your code before promoting to production, or you may get a surprise or two. 🙂

Console logging

If you are using Firefox (with Firebug) or another browser that supports console logging, then you need to experiment with this feature. It is far superior to the alert() command as it doesn’t stop the program flow, It doesn’t impact the blur and focus events of your elements, and it supports logging of hyperlinks, multiple arguments, printf strings, color coding, types of messages (debug/info/warn/error) and more. You can find more information here.

Merely insert the command console.log(‘My message here’); into various places in your JS code, and it the messages will output to the console window in firebug, as the JavaScript code is running.

The example below demonstrates the use of console logging.
consolehtmlconsoleoutput

Simplify and externalize

When you are working with hundreds of lines of complicated JavaScript code, and are having difficulty figuring out a bug, it is often best to reduce the issue to a simple case and test it inside a workbench designed for the task. JSfiddle is a website which offers this type of workbench. It has areas to paste in your HTML, JavaScript and CSS and then it will show the results in an output window. It’s an awesome quick way of isolating your small code snippets and making sure that the syntax works correctly. You do not have to save anything to the server, it just works right there in the browser. I used this technique recently to debug timing events inside JavaScript and realized that the firing order of the keypress event will not give you the full contents of the cell which fired the event. This issue stumped me for quite a while, until I did some tests inside JSfiddle. Now I use the keyup event instead. Here is the fiddle that I ended up with. http://jsfiddle.net/4Mekq/3/

jsfiddle

Step through the code

Of course there are time where you just need to step through the JavaScript code line by line. I almost always use Firebug for this also. For the most part, when I get the JavaScript code running in Firebug, it will work in the other browsers that I test.

In Firebug, 1) Click on the Script tab. This will show all your JS that your web page accesses (even external JS). 2) Click in the left margin where you want to set breakpoints. 3) You can step through or run-to-breakpoint your JS code as you are testing your web page. 4) On the right side (in the Watch tab), you can setup variables that you want to keep an eye on as you step through the code, or you can simply interrogate the webpage object heirarchy.

firebugdebug

Some additional tips:

  • Be aware of the timing of Javascript events. They are not always as obvious as they seem. A simple event firing in an unexpected order can mean hours of debugging on your part.
  • ***My Opinion only*** Don’t use the keypress event when retrieving the value of the field which is triggering the event (it doesn’t get full field with the new key) or blur (this gets the wrong field). Instead, use the keyup event.

In my next three Blog posts I will be highlighting a number of tools and techniques to help answer the following questions:

  • Are my values stored in JavaScript correctly?
  • Is my server code correct?
  • Am I passing the correct information between LANSA and the web page?

Andy

LinkedIn
https://plus.google.com/+AndyBain
@jandybain