There has been a lot of talk over the years of how to get your telnet applications to the web or at a minimum change the user interface (UI). I have lost count of how many times my database supplier Rocket Software for the last 10 years and IBM before them have told me how easy it would be with this tool or that tool to do this. Most of those tools are long since gone and replaced by others every time I see a new demo or “training seminar” from them. Every example that is shown is so simple you have to wonder why is this so hard. Then it dawns on you that have are just showing text boxes, images, or other uncomplicated things.
There is a simple example that I will show you what I mean. Almost all telnet applications have user input and programmers need to verify this against a code file to get verifiable data. For example, the users enter an employee type code such as “DW” for dock worker or “FO” for forklift operators. We verify that “DW” or “FO” is in the code file before we let the user go to the next prompt in a telnet program. All the user sees is an empty box in that type of UI. The backend software is doing all of the work and telling them if the data entered is correct.
On the web, we change the plain area to a select box. A SQL/SELECT statement is written to select all of the records in the employee type file and display them to the user. That way you do not have to keep verifying the data every time the user types in the UI because you have allowed only valid data that can be selected.
The first complication sets in if this field allows no value you have to change the select to have “Pick-a-Value” or “Please choose” that equates to no value. This means you cannot easily select all of the values from the code file because you need to prepend a null value onto the list and must do this programmable. You can do this with UniBasic code in our database or using a function in SQL to concatenate on to your select.
The second complication sets in because once the user sees this UI, they want it to autocomplete. Oh really, that was not even how the prior application even worked. Welcome to the web because those users have spent time on Google, Amazon, eBay, and others to name a few and they work that way so why does not yours. Of course, the JavaScript library tools I use to support these select types: select, combo, multicombo, multiselect, and richselect. All of those types all have additional options that will keep you busy for hours.
The third complication sets in because the code file you have is not as simple as employee types. This file, for example, is customers in which there are about 100,000 records. You cannot have a 100K select box that would be awful to load and be unusable. The solution is called lookups which are concealed in the text box in the right or left corner with an image of a magnifying glass. After the user presses the UI magnifying glass they are presented with a table of the first 15 to 20 values. The bottom of the form has page numbers to show you how many pages there are or just shows a left arrow on the left and a right arrow on the right with a few page numbers in between that is called pagination.
I have completed a few complications about SELECT HTML code boxes that can have lots of complexity. There are many other issues that were glossed over in many of those demos I saw and you may have seen as well, while this article has taken the time to show you one piece of this web-based UI puzzle that hopefully shows you what it takes to complete just one specialized prompt.
I have just finished an upgrade from our prior JavaScript library to a new JavaScript library that changes our entire UI. There is a lot to learn even for this old dog and SELECT boxes were just one of the many different UI choices that were made during the upgrade.
