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…
The side of the road we drive on
Food nutritional labelling
International time and daylight savings time
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…
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 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
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?
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()
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?
Is my server code correct?
Am I passing the correct information between LANSA and the web page?
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.