Tag Archives: Coding Tips

Standards, Standards, Standards

Standards in our everyday life make things easy for us. We often take them for granted, but they are everywhere around us often representing thousands of hours or research and trial and error. Standards inform us, they save us time, they pave the way for building new inventions and processes, they even keep us safe.

Can you imagine how complicated it would be if there were no standards for the electrical sockets in our walls, you would have to tell the hardware store which builder built your house to make sure that a new appliance or lamp would work in your home. We already often experience this when we travel to a foreign country, and currently there are only around 20 common ones used around the world.

Some standards that affect our everyday lives…

  • Building codes
  • The side of the road we drive on
  • Food nutritional labelling
  • International time and daylight savings time
  • Our currency
  • The Internet, Wifi, and TCP/IP
  • Is the pedal on the right, the brake or the accelerator
    I think you get the idea, standards are all around us.

On the technical side of things, “Standardization can help to maximize compatibility, interoperability, safety, repeatability, or quality” (Wikipedia).  It is my belief that crucial parts of developing standards are documentation and communicating it to others. Most developers hate creating documentation (myself included), just grab a keyboard and start coding, so standards are not made or communicated.

I would like to share some standards that I have created or adopted from others over the years. Nothing earth shattering, but maybe it will help some others come up with standards of their own, and increase their code quality and ease of maintenance.
In my next blog entry, I will be listing out some of these standards. Stay tuned…

Formatting Phone Numbers – followup

The code which I originally put together on my previous blog entry was US centric…I have adjusted it to make it more flexible, and to be able to handle more countries.

The parameters have changed.  1) End users input 2) expected number of digits (after removing all other formatting) 3) Description of the target format (& denotes a substitution at that position.  The single digit following an & denotes how many numbers to use from the phone number in that spot.

The full code can be downloaded from here

Calling the routine

Here is the code

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

Debugging LANSA WAMs
Debugging LANSA WAMs

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”
Debugging with firebugNow 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.

Debugging with firebug

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?



Saving state/data without defining a bunch of temporary variables

2013-11-14 00_42_02-LANSA Editor - AJBTEST ( Form_ ) - test


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.