Debugging 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]

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.

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/

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.

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

Many Layers

Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. A web application encompasses multiple environments (E.g. server language, TCP connectivity, HTML, JavaScript, jQuery, etc.) and each one may require a different skill-set to deal with. This compounds the possibilities of errors. To make matters worse, browser standards have always differed from one browser to the next.

The LANSA language goes a long way towards simplifying the different layers but there are still times where some bug has ended up in your application and needs to be found and eradicated. Over the years of developing LANSA web sites, I have found that there are some tools and techniques which are invaluable to finding and squashing those bugs.

Break it down

I find that the easiest way to find and remove those bugs in LANSA WAM applications is to break down the areas of focus into five areas. Ask yourself these five questions.
1) Are my client side objects what I think they are?
2) Is my client code correct?
3) Are my values stored in JavaScript correctly?
4) Is my server code correct?
5) Am I passing the correct information between LANSA and the web page?

These questions are not in any particular order, just start with the one which you think is most likely the area which is malfunctioning. Often you will know right away which one is most likely causing you issues. Answering each of these questions requires a different approach.

Are my client side objects what I think they are?

When working with web applications, we often have to reference elements inside of your HTML document. E.g. you may need to grab a value from a TD element in a table or a value from an input field. However, one of the more difficult tasks is knowing that your Javascript/jQuery is referencing the correct object. If you are not already using jQuery to do your Javascript work, you have to start now! It tremendously simplifies your Javascript coding and makes your client side code very powerful. There are other Javascript frameworks around, but this is the one that I am most familiar with. Always try to reference your target fields via ID or Classes. This makes your jQuery code simpler. You can find information about jQuery here.
The tool of choice for me here is Firebug. If you are building a public website, you should be testing for multiple browsers. Likely Firefox will be one of those browsers. Firebug is a plugin for firefox, and makes interrogation of webpage elements and Javascript much easier. You can find information about Firebug here.
Start up Firefox and click on the firebug logo in the top right toolbar and select “On for All Web Pages”
Now load up your page and you should see a firebug panel at the bottom of your page. You can right-click on any element on your page and select “Inspect Element with Firebug” to review the HTML. It also allows you to review the JavaScript and will show any JavaScript error on the Console panel.
Our objective in this step is to ensure that your JavaScript is referencing to correct objects in your web page. E.g. you are not getting the output that you expect, and you think that your object is not being populated properly. 1) Click on the Console tab. This will allow you to see any JavaScript errors and your output from the next steps. 2) Type in a string that allows you to view your object. This is where the magic happens….when you are building your site, assign as many ID’s as you can to your HTML objects E.g. button’s and fields. If you cannot assign an ID, at least attach a class and make sure that it’s unique on the page (the exception is for repeating table entries). Once these objects have ID’s or Classes, you can reference them using the jQuery selectors. Type in the jQuery syntax (E.g. $(‘.myClass’) for a class or $(‘#myID’) for an ID) to select an object, and then you can use other jQuery commands on this object to make sure that the element that you are looking for in your web site code is the correct one. My example below shows the “Type” attribute on a button that has the class of “submit_button”, but I could have just as easily shown the value of a hidden text element. 3) Press the Run button, your output will be shown in the lower left window.
Use this technique to make sure that your onClick handler is attached to the right button, or that your handler is pulling the desired data from the right field, Etc.

Some additional Tips:

• You can use .parent(), .children(), .next(), .prev() to navigate around the HTML document….this is very useful in a table. E.g. $(‘input#name’).parent().next().html()
• Straight Javascript code can be used and run in the bottom right window. This can be used to interrogate an array or any type of Javascript object.

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

• Is my client code correct?
• 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

Variable Scope

In RDMLX (The LANSA language), variables have a global scope. This means that it’s really easy at times to accidentally clobber a field which you are using, by using the field for more than one purpose. It can be argued that all fields should only be used for one purpose in a program, but there are scenarios where this can happen. E.g. You may be using a field to represent the selected value in a drop down list, and you may also be using the same field to populate the value when building the list.

Global variables have historically been a cause of subtle bugs. A couple of options exist to try and alleviate this problem. Any code that would be better with a local variable scope can always be externalized into a reusable component (The first option). This will also go a long way to minimize coupling. However, if you do not want to re-architect your program, but still need to prevent your variable from becoming contaminated, you could always backup your variables at a convenient location and restore it later when you need the saved values back (the second option).

Use a List

If the save and restore have to handle more than a few variables, it becomes cumbersome if you are just using temporary variables to store the data.

The solution shown in the image above defines a working list with one record. Then when you want to backup the data, you merely do an ADD_ENTRY to_list(#LISTNAME). And voila, you have saved the current state of these fields. Once you are ready to restore the state of the fields, you can do a GET_ENTRY number(1) from_list(#LISTNAME) and you variables have been restored.

This techniques tends to reduce the need for work fields, and can reduce the coding required to accomplish the same task.
Less work fields and less code = less bugs.

Andy

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

Why a blog about LANSA

There are many excellent application development technologies out there. Over the last 30 years I have had opportunities to work with many of them and built many enterprise applications with interfaces that included character based, web, windows, XML. In 1998 I had pleasure to be introduced to one language that I believe really stands out. The LANSA vision is built around the concept of a central repository. This repository manages business rules, triggered activities, dictionary of files and fields, reusable components, and many more great features. The power behind LANSA is that using one base language, a developer can wrap any presentation (including native iPad/Android) around this repository; It has multilingual features and supports multiple databases types. To top it all off, should you decide to move your application to a new platform, it supports Linux, Windows, iSeries production environments.

Having taught LANSA for many years, I have found that it is very easily understood by all the students and they are off and running very quickly. It has standard structured language constructs that many of us have studied while learning programming. It’s easy to learn, and produces enterprise quality applications. There are other languages which I enjoy using, but you can definitely say that I am a LANSA Fanboy.

Why LANSA cookbook

Purpose of the blog: LANSA as a software vendor has some incredible documentation, and if you have not yet checked it out…you can download it here. However, I believe that
us computer geeks often go to Google first when we get stuck or need tips/techniques, or need to see some sample code. I have for a long time envisioned growing an online presence that would assist developers, not by posting questions, but by posting solutions….solutions that may help others doing a Google search. The blog is inspired by Perl Cookbook, one of my go-to books from the mid-90s for a popular language that I was using at that time. Not sure if I am up to the challenge, but I am going to give it a shot.

Format: I decided to put this collaboration site up in blog format to give me more control on the content and format. This seems like the right format at this moment, however, there is a possibility of change if at some point I feel that another vehicle will deliver the message better. I already know that my solutions will not always be the most elegant, or the only solution for that matter. They might be downright clumsy, but they are a starting point. Comments will be left enabled (but moderated). I encourage you to comment if you think that there is a better/cleaner/faster/bigger/stronger/prettier solution or a way to improve mine. Other sites have been successful using this model. E.g. See this PHP documentation page to see how contributors add to the information available on the page.

Networking: This blog is meant to be for the good of the community. I am putting out a call to guest bloggers. If you want to post a solution, please write it up and send to me, and I will put it up as a guest post under your name. I would also like to reach out to all you LANSA developers and use this as a platform for networking. Please feel free to make contact with me if you have any questions or want to network.

Andy

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