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

Squash those bugs

Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is part three 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 “Are my values stored in JavaScript correctly?”

Are my values stored in JavaScript correctly?

When working on web pages, to make sites as interactive as possible, you will often need code in at least two places. The server, which in this case would be the LANSA application server running on an iSeries or Windows box, and the client would be a miriad of browser types running HTML and JavaScript. The mixture of HTML (for presentation) and JavaScript (for interactivity) is a very strong match. It gives web applications the power and functionality that is often attributed to windows GUI applications.

JavaScript is a very power language, but often the code can get quite complex (depending on the business requirements) and debugging can be difficult. As always when debugging difficult JavaScript, I turn to some of my time tested trusty tools. Firefox, jQuery, and Firebug. These tools allow me to step through the code and review the state of element values and change them if necessary.

In the first couple of installments we looked at inspecting objects and stepping through code. What we are looking at this time will be values stored in variables elements.


The first priority is to make sure that all fields (or at least the ones in question) have a “Handle” that you can use to interrogate it’s value. HTML allows a developer to attach these handles in the form of ID and Class parameters. Classes allow accessing multiple elements at the same time and are heavily used for presentation by Cascading Style Sheets. What we are interested in here are ID’s. LANSA automatically assigns an ID to every element that needs to carry data back to the server. However, if you manually add HTML in the IDE, I recommend that you add an ID tag to input/checkbox/radio/dropdowns, etc.

For fields in tables, the format that LANSA uses is <LISTNAME>.<ROWNUMBER>.<FIELDNAME> E.g. LSSKILLS.0001.SKILLDESC


<input id=”LSSKILLS.0001.SKILLDESC” class=”utext” value=”RDMLX” name=”LSSKILLS.0001.SKILLDESC” size=”60″ maxlength=”80″ onchange=”return isValidText(this, ‘ ‘)”>


For single fields, the default ID is the field name. E.g. STD_DESC


<input id=”STD_DESC” class=”text” value=”” name=”STD_DESC” size=”30″ maxlength=”30″ onchange=”return isValidText(this, ‘ ‘)”>


The next step is to ensure that you have included Jquery as part of your includes in your HTML HEAD tag. Here is an example;

<script charset=”iso-8859-1″ type=”text/javascript” src=”/images/jquery/1.7.2/jquery.min.js”>


The final step is to load your page into the browser and start Firebug Console mode. Inside this console you can use jQuery syntax to interrogate your fields. See image below.
Squash Those Bugs


  • The jQuery syntax for displaying the value of an input field in the console is $(“#NAME”); Where NAME is the value inside the element id.
  • All jQuery commands can be run inside the console. Refer to jquery.com for more command syntax
  • When dealing with List Fields, there will be periods in the ID. E.g. LSSKILLS.0001.SKILLDESC. These periods will need to be escaped with a double backslash. E.g. LSSKILLS\\.0001\\.SKILLDESC
  • Firebug can you used to set breakpoints so that you can stop the code at a certain point to interrogate these fields, or you can step through the JavaScript as it’s being performed.

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

  • Is my server code correct?
  • Am I passing the correct information between LANSA and the web page?