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…

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

I noticed a recent post on the LANSA2 Yahoo Group that was requesting the best method of scrubbing a user entered phone number to format it in a certain way.

There were no LANSA centric solutions given, and some of the other solutions may have worked just fine, but as this was a LANSA forum, I thought I would throw a LANSA solution in.

I could not find any real elegant solution in LANSA (like regex), but have created a small routine which would scan the input string remove all non-numeric characters and reformat based on a format passed in from another input string.

Currently this only handles 10 and 14 digit phone numbers. (14 has the country code in front. E.g. 011 for North America). I will create a similar routine another time for credit card formatting.

Simply put this method routine in your RDMLX code, and call it using the following statement(s). The method “FormatPhoneNumber” takes 2 parameters. 1) The input string to be formatted and 2) the format that will be used with an &# for each part of the phone number.

The first call above handles 14 digit phone and the second handles 10 digit phone numbers.

The code is shown below, and can be downloaded here.

Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is the final part 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. Part two can be found here. Part three can be found here. Part four can be found here. This installment helps you answer the question “Am I passing the correct information back to LANSA?”

As stated on previous articles, there are multiple possible failure points when developing a client server application for the web. We have looked at debugging on the client side (browser), the server side (AS400 or Windows) and we have looked at how browser scripting plays into the equation. There is one final piece of the puzzle which may help if you get into a real difficult situation and need to pull out the big guns. Sometimes you need to analyze the traffic that is flowing between your browser, and the LANSA server.

Introducing Fiddler

Fiddler is one such tool which will allow the developer to view data being sent to the browser and their responses. The tool has many other features and can even allow you to “tweak” the data for testing purposes. It can also show cookies, and headers (which, at times, are both used to transfer data between the browser and the server).

Over the last 15 years, on a number of occasions, I had to reach out to LANSA support to assist with a web development issue, due to some unexpected system behavior. Many of those times, the first thing that support did was load up fiddler and inspect the data movements. It is a very powerful tool!

Fiddler gets installed on the developer’s workstation, and works like a proxy server. it intercepts all traffic initiated by the browser, and forwards it to the server. It also intercepts the responses, and documents the data for you to inspect, and verify.

Sometimes the problem with your application may be as simple as the date coming back is in the wrong format, or a text value coming into your JavaScript is left aligned, when you expected it to be right aligned. Fiddler will come in useful during those type of issues to verify the accuracy of your data.

Firewall issues can also be detected using the fiddler tool as it documents the time it takes for a transaction and it shows the status of the HTTP request.

Make Your Request

Once fiddler is installed, it needs to be running so that it can intercept all browser traffic. Then load your web page using the browser, and step through until you get to your code in question.

As can be seen in the example above, there is data entered and transferred to/from the server.

Breezing Through Traffic

Switch over the Fiddler, to view the transfers.

Fiddler is broken up into 3 sections. The left panel has one entry per HTTP request. You can select which entry you want to inspect here. The top-right panel shows a ton of information about the outbound request from your browser, it shows cookies, headers, form data, URL, etc. The bottom-right panel shows a ton of information about the inbound response including cookies, headers, form data, URL, etc.

Outbound Request

Clicking on the transfer on the top-left, we can then look at that specific transfer. We then look at the top-right panel (shown below). This has a number of tabs. When we click on the headers tab, it shows the URL used (which sometimes has data appended to it), and additional headers and cookies.

When we click on the webforms tab (shown below), it shows all the field data being sent to the server.

There are all kinds of data which can be analyzed on the outbound transaction. It even has tabs for properly formatting JSON and XML request.

Inbound Response

When we change our focus to the bottom-right panel, we are looking at the data coming back from the server to the browser (if any). Again it logs, headers, cookies, inbound HTML Etc. If we select the “Textview” tab (shown below), we can find our fields and the data passed by searching for them in the searchbox on the bottom of the page.

Using the techniques shown above the developer can review the data being passed in either direction, and determine if the data integrity is contributing to how well the application is working.

This tool can also be used to help diagnose network based Performance issues as it shows the http response codes. It shows how long it takes for the responses to get back. It shows additional http requests which may have been spawned by the original one to do things like retrieving images. It even has a statistics tab which will estimate response times to other parts of the world.

I encourage you to install the tool, and play around with it. It can give tremendous insight to a developer who needs to verify or validate the integrity of their data as it arrives at the client or the server.

This concludes the series on effectively debugging LANSA WAMs applications. Most times, debugging will not require all the tools that were laid out in these blog postings, but with these tools as part of your debugging arsenal, I would put forth that there are few bugs which will out of your grasp to seek and destroy.

Happy Hunting!

Andy

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

Debugging web applications in general tends to be quite complex, and requires some extra planning and thought. This is part four 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. Part two can be found here. Part three can be found here. This installment helps you answer the question “Is my server code correct?”

Is my server code correct?

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.

RDMLX is the LANSA language that runs on the server. It is originally designed on BASIC structures and over the years has evolved into a very mature language that rivals all the big names like C++, Java, Etc. It is reasonably easy to pick up and be productive quickly, and can be ported to different platforms if required. When running LANSA WAMs websites, RDMLX is the code which is running on the server side. Development of the RDMLX code is done in a modern Visual IDE. This IDE has some great debugging features. The IDE is a window rich client application which runs on the developer’s PC, and allows the developer to “check-out” code from the server, to work on that code, and then to send it back to the server to run. Another great feature of this IDE, is the ability to debug code running on the server. This is the feature that we will explore in this article.

Architecture and Flow

1. The debugging process starts at the Browser. A URL is called which tells the server which WAM to run, to run it in debug mode, and where the IDE is that will do the debugging.
2. The server contacts the IDE, to have a 2 way conversation, passing back and forth the variables and the line which the server is currently executing
3. Using the IDE, you can set breakpoints, change variables, and step through the code to observe your application behavior.
4. Once the program has completed it’s tasks, the server sends the resulting HTML page back to the browser.

• All code actually runs on server
• All database IO occurs on server

Setup Steps

Some developers do not use this great capability because of the setup steps involved and possible complications. However, once you know what to check, setting up a debug session is a snap. Here are the steps that I always go through….the first time running a debug in a specific environment.

1. Your WAM needs to be checked-in/compiled with Debug turned on. Shown below is the check-in dialog box.
   
   
2. Check the current IP address of your development PC. The IBM I will use this IP address to contact the IDE to do the debugging. The IPCONFIG command can be typed into a dos window. Keep in mind that if you are on a VPN..you will need to be using the IP address from your VPN connection. You should be able to ping your PC from the IBM I.
   
   
3. Ensure that the debug setting inside the IDE are setup correctly, and on a port which the IBM I can use to connect to the developer PC. This dialog can be found in the IDE menu options/settings/debug.
   -If the debug does not work, you need to make sure that there are no firewalls between the IBM I and the developer PC that may be blocking port 51234 (default)….This includes the windows firewall.
   -When you first start, make sure that the “Break at first executable statement” checkbox is checked (this is to prevent confusion if the debug session never passes your breakpoints). As you get more advanced, you may start running debug from a different point.
   
   
4. The LANSA Server environment needs to be told that debug can be run. This should only be done only for the development environment. You can leave debug disabled for production. This setup step can be done in the LANSA Web Administrator tool which was used to setup your web environment. In this tool, you go to menu tools/configure systems/data-application server. Under the miscellaneous tab, you need to check the “Allow interactive debugging” checkbox.
   
   
5. Setup your breakpoints. These are point which will stop a debug so you can step from that point and inspect variable. Breakpoints can be set by putting the cursor on a line and pressing F9. Breakpoints show as a line highlighted in red.
   

Doing the Debug

Now that your environment is setup, you can step through the server side code of any WAM application. To start a debug, your WAM has to be compiled (with debug on) and checked-in to the server. Then you go to the design tab on your IDE, and press the magnifying glass.

If the setup is correct, you should get a debug session loaded in your IDE. You should be able to step through your code using F8 (step into). You can also use F5 to run until the code encounters a breakpoint. Inside the IDE, the yellow lines indicate what line in your program is about to be run, and variable values can be inspected on the left of the interface. Variable can also be changed…for testing purposes.

Remember to recompile your WAM with debug turned off once you have completed your work. Debug adds about 40% to the size of the code, and will likely make the code run slower.

This type of debugging can be a huge time saver when finding those nasty hard to find bugs. It allows the developer to notice any piece of code where the logic goes in the wrong direction, where unexpected values come out of files, or some typo causes your application to go down in flames. This is a tool which every Web developer should have in their arsenal.

In my next and final blog posts on this topic, I will be highlighting another tool and techniques to help answer the following questions:

• Am I passing the correct information between LANSA and the web page?

Andy

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

I know….I started a 5 part series on debugging WAMS, and the series is not done yet. It has been a very busy past few months. More installments will be coming shortly, and they are good ones. However, I recently had an opportunity to use LANSA LongRange. The new(ish) LANSA tool for building apps to deploy on Mobile devices. I thought I would take a few moments to document my experience and give a review.

My Rating: 4 Stars (out of 5)

LANSA LongRange is a Native Mobile app development tool which allows the developer to use either LANSA code or RPG to drive the application.

• Without learning a new language, the LANSA developer is building pages in no time. The applications built with this tool are cross platform and are deployed to the end user as a native app for iPad or Android.
• The tool includes a schema editor. The schema allows the user to setup buttons and menus which would used by the screens. Not much time was spent in there…it was used mostly in the beginning to build the menus for each page, and then only once in a while when adjustments needed to be made.
• When running in online mode, there is no presentation or data stored on the mobile device. The presentation, business logic and the data are all stored server side.
• When building code, you actually send instructions to the mobile client where fields, tables and objects are stored on the screen. Some may not like the presentation layer being mixed with the logic, but in this case, it has a very big benefit.
• Changes require no new deployment. Changes are rolled into production on the server, and immediately show up on the mobile client.
• The app store has a LANSA LongRange app in it. This would be installed on all the clients, and then your server side code does the rest.

Overall, I enjoyed working with this tool. I worked with a team which built an application consisting of about 8-10 very complex pages and integrated with legacy backend systems seamlessly. The pages had many advanced features like attaching photographs, capturing signatures, and validation of all the input data with highlighting of fields in error. In the backend we also have a PDF generation component (using LANSA Integrator) which allowed the signatures to be added to the PDF’s. We took the online approach, which means that all our data is stored directly and immediately on the server. The end user would require a full time connection to use this application. This was a design decision as the tool supports offline application development as well. We took approximately 3 months to build the meat of our application with about 2.5 developers. More time was spent afterwards going through the QA process, and dealing with requirement changes. We had no real training, but reviewed the shipped documentation and had some mentoring by someone experienced with the product. Having someone experienced on the project was invaluable, and while the tool is fairly easy to use, there are some nuances that would cause a new developer to spin their wheels (or make a bad design decision) if left to their own devices. I am aware of another team elsewhere who is building a similar mobile app, and has been at it for a long time with a cost of more than 10 times what this project incurred. This tool does not feel to me to be completely mature yet, but I am sure that with time LANSA will fill out the extra “power” features which will make this into a 5 star tool.

The Positive

• No new language to learn
• No new Editors to install (only partially true… A schema editor was included, but all real code was built in the standard LANSA IDE)
• Complete and seamless integration with all your server files which you are already using, and all your existing LANSA code libraries and objects
• Application changes do not require full re-deployments
• Trace logs were built in to simplify debugging
• Online/offline capabilities
• iPad and Android compatibility without having to learn multiple languages. My experience is only with the iPad.
• No communication layer required to be built so that your app can talk to the server
• Apps could be built purely with your iSeries developers. Nobody needs to learn Objective C.

The Negative

• Better documentation required
• No WYSIWYG screen design tool
• It wasn’t clear to me how to step debug

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

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.

Steps

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

[code]

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

[/code]

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

[code]

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

[/code]

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;

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

[/code]

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.

Tips

• 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?

Andy

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

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