Time to turn a new page and start a new subseries in which I will discuss a few ideas about UI. Let’s start by contextualizing the topic and explaining some important aspects.

This subseries will cover two main topics:

• How to restructure your code to facilitate a UI (user interface) modernization initiative
• How the MVC (model-view-controller) design pattern can help achieve that goal

I’m also thinking about including a brief explanation of RPG Open Access and some tools that use this great RPG enhancement to facilitate the modernization of a legacy application’s UI. Let’s start with a simple question that has a somewhat complicated answer:

Why Separate the UI Code from the Rest?

One of the many advantages of coding in a modular and structured way is being able to reuse code. This is great, especially because you probably have a lot of programs that have common code when it comes to UI, database access, or business logic. These three things form layers in most of your programs. Isolating the code related to these layers is usually not an easy task, especially if you’re not used to it. Earlier in this series, I proposed a Lego-like solution, which is the core concept around a good and proper ILE program: there are modules and/or service programs for each layer, and a “main flow” module handles the user interaction and controls the main flow of the program.

Now it’s time to take the next step and explain how you can use this layering to modernize your UI. It can be a lot of work, but it has several important benefits:

• Reduce complexity—UI code is typically different from the rest of your RPG code. If you follow the guidelines in this series, your non-UI code won’t have indicators, for instance. Things can get pretty hectic when you have a lot of conditional formatting going on, such as choosing the right color or content for a field according to certain data-driven conditions. From this perspective, isolating your UI code will lower a program’s complexity and help streamline the whole process.
• Increase maintainability—By lowering the code’s complexity, you’re also increasing its maintainability, because smaller, more objective, and (hopefully) better-documented pieces of code are easier to maintain.
• Allow the workload to be shared—A modular approach allows you to break down the “construction” of a program into smaller tasks and distribute them among several programmers. You can even have specialists in different areas building different bits of code. Going back to the Lego analogy, your database expert can take care of the blocks that will handle the database operations related to a file or group of files, while your UI expert is simultaneously building the blocks that will make up the application’s interface with the user. These tasks can run in parallel, and in the end it’s simply a matter of putting the blocks together to build your program.
• Allow different and more flexible UIs—From personal experience, I can tell you that I’ve changed more code related to UI than anything else. While many UI changes might be minor details, such as adding a field or changing its attributes in certain conditions, it’s undeniable that we spend a lot of time changing the UI. By having it isolated from the rest, you can assign those tasks to the “UI experts” on your team and focus on other areas of the application. This might come as a shock, but your UI expert doesn’t have to be an RPG programmer. Actually, he or she might not even know what RPG is! As long as the pieces of code fit together, it really doesn’t matter. This might sound a bit strange, but you’ll see what I mean later.

Building Your Programs the Modern Way

In a typical Old Problematic Monolithic (OPM) program, all the functionality is contained in the same source file. This means that all the user interaction, database operations, and business logic are intertwined in an OPM piece of code. I’ve been preaching (and showing) the virtues of ILE. The modularization approach I’m about to show you is a step toward code and UI modernization. This approach assumes three things:

• Each module contains all the functions of a certain type or that operate over a certain item (file, business process, generic utilities, calculations, and so on).
• Each service program only has only one module.
• Each service program has its own binding directory.

The typical OPM program is self-contained, or almost self-contained if it eventually calls some helper programs as explained way back in the series. ILE programs, on the other hand, are made of many building blocks (functions and procedures) glued together by a “main flow” module, the backbone of an ILE program. From a structural point of view, it’s important to have the code well-organized in order to achieve maximum reusability and optimized maintenance. Figure 1 shows how, conceptually, an ILE program should be structured.

Figure 1: The ILE program concept is a multi-tier architecture implementation.

In this multi-tier architecture implementation, a program is composed of blocks arranged in three tiers or layers:

• Main flow—This tier handles the user interaction part of the program, as well as the main control flow of the program. This means the main flow handles all user-related input/output operations (either to a display file or a printer file) and provides the backbone of the program, calling procedures and functions in order to make things happen.
• Business logic—Sometimes known as business rules or business validations, this tier is responsible for the validation and enforcement of business requirements and rules. As described in the previous subseries, many of these validations are in the database, or at least in isolated modules.
• Data access—Finally, this layer handles all the data access. Here’s where the I/O Servers also described in two articles of the previous subseries come into play. They’ll handle all I/O operations for your programs. This should be totally independent from the other layers in order to maximize reusability. For instance, function Crt_Client_Record doesn’t know (and shouldn’t know) whether the client has a good credit score; that’s a job for a procedure of the business logic tier.

Coming Up

In the next TechTip, we’ll apply this conceptual approach to a practical situation. Until then, feel free to comment, question, and share your experiences in the comments section bellow.