Using Variables to Host Data in Code

It’s worth mentioning, from the start, that there is no such a strict type called CONSTANT in Ring. We just have variables that we can change any time.³ In my case, when I use a variable as if it were a constant, I write it in uppercase so I can visually identify it. Then I assume my own responsibility, as a programmer, is to treat it as a value that I will never change at runtime.⁴

It’s language abuse then if we talk of constants in the scope of Ring programming, but we will do it anyway. Consciously.

This seems great, but wait.

Avoiding Magical Numbers

3 is a magical number in this code sample, meaning it’s a value that is hard-coded without any meaning other than what the code writer knows. In fact, I know it is the number of years, because I am the one who wrote it, but how this can be conveyed to other readers without ambiguity, especially when we are programming “on the large”?⁷

Then replace all the with numYears, like the following, for example:

numMonths_3Y = NB_MONTHS * numYears    # Gives 36 months

Now, think for a moment about the names of these variables: numMonths_3Y, numWeeks_3Y, and numDays_3Y. What is wrong about them?

There is no consistency in our naming strategy. Having the _3Y postfix in numMoths_3Y no longer makes sense, since the number of years, now hosted in numYears, can be changed to any value other then 3. This is the showcase where 3 is not only a magical number but a magical and hidden defect in the same time!

So, never rely on a name like numMonths_3Y for your variables. Also, note the changes I made to the text of the comments (in bold in Listing 3-4): we are no longer referring to 3 but to a given number of years!

This nice feature solved part of the complexity that is still there,⁸ inside your code.

Mitigating Code Complexity

Currently, our program structure exposes a serious threat regarding the order of execution of the variables hosting our data. Let’s analyze it by looking closely at Figure 3-1.

This kind of dependency, owing to the use of global variables, is a bad thing, especially in large programs, because it makes your code hard to understand and fragile at the same time. Why hard to understand? Because you can’t find where it changed and how the chain of changes has impacted the ultimate value of the variable in the current place of your code. Why fragile? Try to move part 4 before part 3, for example, or part 3 before part 2, and then execute: it will break!

The morale of the story is that global mutable state can be evil.

There is a hot discussion in the programming community on whether mutability, the change of global variable values, is a good or bad thing.¹⁰ Some say it is a bad design, while others claim it gives them freedom. You should make your own decision based on your particular programming style and real-world context.¹¹

Personally, I start by thinking about the algorithmic problem in hand, without limiting myself by this immutability paranoia. My data is defined in front of my eyes, right in the code, using constants, global variables, and local variables alike. Once I’m done logically with the solution, I take out my perfectionist sword and start iterating on localizing the state of the program as much as possible by transforming globals to local variables.

Usually, this means my code parts are redesigned in functions (or classes) while separating between concerns, as much as I can, so every function gets one and only one clear mission. That’s why I expressed my concern about the program structure and its flow of execution, as shown in Figure 3-1. This is what refactoring means after all: good naming conventions, minimal dependency between variables, careful separation between concerns, and the design of independent but complementary parts of the overall program.

Did I say refactoring? Let’s refactor then.

Refactoring the Data Side

In particular, those functions should be independent and self-contained so they always return the same result if they are fed with the same input data and can be called in any order.¹²

At this level, it’s sufficient to know that : can be used inside a hashed list as a decorator of the index used to access the corresponding value. But in reality, the : is a general replacement in Ring of "" in delimiting the value of a string. Hence, for example, instead of saying s = "sun", you can say s = :sun; it’s the same.

You may be asking, why do we use these colons to access a hashed list? Well, what happens behind the scene is worth explaining.

Then we can write the following, by just replacing with   , and replacing with , like this:

a = [   [ :name = "Nestor"], [ :age = 48 ]  ]

If you were to cope with the internal representation and if you want to access the name value, for example, then you should access the first item of the a[] list (which is itself an inner list) and then access the second item of that inner list to find the required value, "Nestor". In Ring code, this is equivalent to saying a[1][2], which is exactly what Ring kindly does, for us, when we say a[:name].

Now tell me what is the equivalent of a[:age]? Yes, a[2][2].

As a general rule, Ring takes the string you put as an index between the [], performs a quick search of the inner list containing that string in its first item, and then returns the second item corresponding to the required value.

We can say “Thank you, Ring!” because such a feature enhances our programming experience and enables us to write code while thinking in it naturally and hiding its complex implementation.¹³

Now, after implementing the first guideline by refactoring the data side, let’s move to the second one and refactor the code side¹⁴ of our program.

Refactoring the Code Side

The second guideline mentioned in the previous section can be implemented by transforming every one of the three parts of the program (from 2 to 4 in Figure 3-1) into a function. For example, to successfully refactor this code snippet from part 3 into a clean function, do this:

We are not only more elegant conceptually, but also more precise arithmetically, since the first formula completely misled us. Frankly speaking, the number of days in three years has never been 1008 but 1095 (= 365 * 3).

These can calculate the results for any number of years and in any order. Our code side of the program is now composed of well-defined functions and deservers applause. But...¹⁷

Even those functions are open to an additional¹⁸ and useful refactoring.

Separating Between Concerns

As a golden rule for the design of your functions, let them do one thing and do it well, instead of stuffing them with various features and operations. This is another source of software complexity that you should avoid from the beginning. In our case, the functions we just designed perform two different operations: making the calculation and generating the output. These are two different concerns, and they must be separated.

To do so, an output() function could be added and called from inside all the other functions to prepare the output in a string, without printing it yet in the screen (using ?). Once returned to the calling code, we let the caller decide what to do with it: printing it to the screen, using it in any other computation, or blowing it on the wind! Why should we care?

Execute it and compare the result with the previous versions. They are all quiet in terms of output, but the last version exceeds them all in terms of the quality of software code.

There’s one little thing I want to add to this subject of mastering data in your code: the use of global variables.

Using Global Variables

What about using global variables inside your programs?

As I said earlier when I first talked about mutability, some programmers will say they hate globals because they alter the state of the program, and others will say they do need them because they make their lives easier. Some programming languages don’t support them at all, such as Java and Haskell. Others limit their visibility at the program file level, like Python, and still others can extend their visibility to external files, like C. Some languages define them exclusively at the top level of the program, like C++, while others can have them defined anywhere even inside functions, like PHP. A number of older languages, such as BASIC, had only global variables, no more.

In particular, the programming language Closure features a kind of immutable and persistent data structure that always preserves the previous version of variables when they are modified. Technically, when the programmer changes a new value to an existing variable x, then its old value is preserved untouched, in memory, and a new version of x is created to hold the new value. Such a conservative approach, inspired from the functional programming paradigm,²⁰ provides a radical protection of the state of the program and is good for developing heavy data transactional systems and multithreaded applications.

Is that mutable or not mutable? In such religious wars,²¹ the voice of wisdom is always in between, and to wisdom the Ring language obeys.

Thus, the two variables myVar1 and myVar2 are visible to all the code written in the main region of your program without being globals anymore. You’ll learn more about the visibility of variables at different scopes²² (global, local, and object scope) in Chapter 6.

A lovely global, isn’t it?

Using the Give Command

Executing this code in the tempo.ring file in Ring Notepad (Ctrl+F5) shows the first string as "Enter the first number: " in the Output window and waits for data entry. The data entry is what you type in the Input field at the bottom left of the Output window, as shown in Figure 3-2.

The same thing can be done on the console. Let’s try it (Ctrl+R); see Figure 3-3.

Any problem?

The console was in a hurry and didn’t show you the answer.

Anything is a variable that we used to force Ring to wait until a key is pressed, and then the program ends.

Getting Arguments from the Command Line

where arg1 and arg2 are the two arguments that the Ring executable (in the first case) or the Ring script (in the second case) will receive and work with internally.

Dealing with data coming from outside your program, from the operating system in particular, is not something a modern programmer can escape, since the software domain is moving toward mobile phones, embedded devices, self-driven cars, and autopiloted drones. However, GUI applications remain by far the major interface for capturing data inputs in our software world.

Creating Windows in the Form Designer

The Form Designer can be activated by selecting View ➤ Form Designer window from the Ring Notepad main menu or by pressing the Ctrl+Shift+F keys. Figure 3-5 shows a general overview of the Notepad user interface with focus on the region related to Form Designer.

You can switch between the Form Designer and the Code Editor (currently I have tempo.ring open, as you can see in Figure 3-5) by activating the related tab on the bottom-left side of the user interface. The Form Designer application has a main menu (1), an icon bar (2), a toolbox (3), a workspace (4) containing an empty form (or window if you want), and a Properties panel (5).

The Toolbox and the Properties panel can be turned on/off by selecting View ➤ Toolbox or View ➤ Properties from the main window (of the Form Designer and not Ring Notepad²⁷).

Actually, the Properties panel shows the attributes of the window. Try to change a couple of them by typing a width of 320 and a height of 350, for example, and observe the impact of that change on the window in the workspace.

Scroll down the Toolbox panel on the left side of the screen to discover plenty of graphic widgets²⁸ available by default. To add one to the window, a LineEdit²⁹ widget, for example, click it first, then move the cursor on the window, select a position to start, perform a long mouse click, and start moving the cursor, as shown in Figure 3-6.

Note that the active widget selected in the toolbox is highlighted (so you know what you are working on). Now release the cursor so you have the LineEdit widget painted on the screen, as shown in Figure 3-7.

As you see, the LineEdit widget is still selected, and its properties are displayed in the panel on the right. You can play with them if you’d like. Change the Text Color and Back Color properties if you want by clicking to the right and choosing your preferred colors from the displayed color selector.³⁰

To deselect the current graphic widget, click anywhere in³¹ the window but outside the widget itself. To select it again, click it. Now, you can move³² it on the window by making a long click inside the field and dragging it around (without releasing the mouse). Or you can scroll the mouse over one of its borders and stretch it in one direction or another, as shown in Figure 3-8.

You can even drop it completely by pressing the Delete button in your keyboard while the widget is selected. But I doubt you may need it, since what I want you to do now is to duplicate it by selecting Edit ➤ Duplicate from the main menu (or by pressing Ctrl+Shift+V). Adjust the duplicated widget position to be under the first one. By the way, note that the Edit menu contains other interesting options (but it is not required to go with them now). Also, set the names of the two LineEdits to, respectively, edtNumber1 and edtNumber2. These names will be used later when writing code for our application logic.

Add a button and place it anywhere³³ under the two LineEdits and then set its Text property to Calculate Sum. Finally, add a Label widget and put it under all his friends. Name it lblResult so this name can be used later in programming. Set its Back Color to dark gray and its Text Color to white, for example. Figure 3-9 shows my window right now.

Make a multiple selection of the widgets by selecting Edit ➤ Select Objects from the main menu of Form Designer. When the popup window is displayed, use it to select the widgets by clicking their names successively in the list, as shown in Figure 3-10 (clicking a selected item will deselect it).

I left the last one for you (lblResult); click it and then click the Select button. Your widgets are all selected. Click anywhere in the window to deselect them.

Now try to do it the natural way by drawing a virtual region around all the widgets using the mouse (by pressing the left button, drawing a region around them, and then unleashing the button). Interestingly, you get the screen shown in Figure 3-11.

As you can see, you can take a bunch of smart actions to provide values for common attributes in one operation and organize your widgets on the screen. Apply, for example, Align – Left Sides and then Size – To Widest by clicking their relative buttons in the Properties panel. Our widgets are kindly aligned now and have all the same width. Play with the other actions; they are super powerful and can help you achieve any adjustment you need in practice. In particular, I want you to achieve what’s shown in Figure 3-12.

Adjust them back to the left side.

From our SumCalculator App perspective, the four widgets we have on the window correspond, respectively, to the first and second numbers to be provided by the user, the button we press to launch the calculation, and the text label where the result will be shown. You can add some other widgets to get the same initial window we started the section with, but it’s better to keep it basic now.

Launch the form to see it displayed on the screen. For that, just select Program ➤ Run GUI³⁴ application (no console) from the main menu of Ring Notepad or, as usual, by pressing Ctrol+F5. Figure 3-13 shows what you get.

This is a toy window, though, and some useful functionality needs to be implemented. I'll be more than happy to help you do it, but before that, you really need to understand what is going under the hood.

Understanding the Generated Files from the Form Designer

As we said before, the Form Designer is written completely in Ring. Its source code is available and can be found in the c: ingapplicationsformdesigner folder. You can even include it seamlessly in any of your applications like it was included in Ring Notepad (read the introductive comments in the formdesigner.ring file). Also, everything Ring does, from parsing your program code to transforming it to bytecode to providing you with a complete WYSIWYG system to designing your interactive forms, is totally transparent, and nothing is left, like with other technologies, inside a dark hole.³⁵

So, what happens exactly when our widgets are visually designed?

Save the form by selecting File ➤ Save as from the main window of the Form Designer, select a new folder called SumCalc under c: ingbookchap3, and save the form file there under this name: sumCalculator.rform (note that you won’t need to type the .rform extension because it will be added automatically).

When the form is saved, some files were generated, behind the scenes, all written in the Ring language. Verify them by exploring the SumCalc folder, as shown in Figure 3-14.

Save the form right now by pressing in the icon bar of the Form Designer. Then close it by selecting File ➤ Close from the main menu. Now, let’s open the first file, SumCalculator.rform, in an external text editor, and try to figure out how the form has been automatically described. In my case, I used Notepad++ and hide some lines to get this compact general overview of the file, as shown in Figure 3-15.

It’s all about a simple Ring list called aObjectsList. Every item is a hash list itself corresponding to one of the five widgets forming the application (Window being the fifth one along with the four widgets we added manually to the form). The hash list contains the widget attributes as they were defined in the Properties panel of the Form Designer.

Save it, close it, and go back to Ring Notepad. From the main menu of the Form Designer, select File ➤ Open, and find SumCalculator.rform in the c: ingbookchap3 ingcalc folder. Open it and observe the new title of the form: it has changed.

Now add a text Label to the form, for example, or change any attribute of the current widgets in the Properties panel. Save the form, switch back to your external text editor, and open the same sumCalculator.form file again: it has changed.

Hence, the description file is modified automatically, under the hood, when you change your design of the window in the Form Designer. But also, any other means can be used to change it: manually by editing the text file or dynamically by another program you write in Ring or any other programming language.³⁷

Among the properties of every object there are some events out there. You can easily identify them, by their names, in the Properties panel or even inside the text of the current description file (did you notice the Click event in Figure 3-15?). These are specified here because they are doomed to play the role of a binder (or messenger or mediator or linker if you want) between the description of the user interface in the current sumCalculator.rform file and its concrete rendering (or implementation in Ring code if you want) in the second presentation file, sumCalculatorView.ring.

So, let’s take a minute to talk about events in programming in general before we continue our journey in exploring the remaining generated files.

Understanding Events

Events are the most known source of software complexity. They are both difficult to introduce³⁸ and hard to implement in code. Yet, they are largely misunderstood by beginners and experienced programmers alike, while being prone to divergent doctrines in defining them and rigorously classifying them, even by the gurus of the software industry.³⁹

Besides explaining how events work in a GUI application like the one we are currently developing, its true value resides in the clarity of definitions provided, which you should embrace and understand from the start of your programming journey with events.⁴⁰ During your learning experience, inside this book and elsewhere in the future, you will be most likely confronted with many variations of the jargon used, which is actually one of the additional causes of complexity of the discipline of computer science in general and this subject of events in particular.⁴¹

In fact, a GUI application is a real-time software system⁴² composed of a main window, a main events loop, and a number of graphic widgets. The term real-time means that the main events loop is listening all the time to what is happening inside the window. Its role is to intercept any event fired by the user on a widget (click, mouse-over, etc.) and route the execution flow to the part of code specified by the programmer to handle this specific event. A quiet complex system indeed!⁴³

Figure 3-16 is a visualization that says it all in pictures. Just follow the numbered arrows from left to right.

Figure 3-16 draws the mental model you should adopt while thinking of the big picture of the event-driven system established by Form Designer inside your code base to accelerate the development of the GUI of your application. In fact, among the several actions implicated in the click process visualized in the figure, only actions 4 and 5 are required to be done by you, the programmer. All the others are done automatically for you!

After watching how the UI has been described automatically inside the description file, sumCalculator.rform, let’s see how its presentation aspect has been fabricated in the sumCalculatorView.ring.

Fabricating the User Interface

The file contains a class of the same name, SumCalculatorView , which reproduces thoroughly the content of the first description file, sumCalculator.rform, while augmenting it with some implementation staff: a Ring class and a bunch of Ring libraries (StdLibCore⁴⁸ and GuiLib⁴⁹) along with a package⁵⁰ of specialized classes in GUI programming, System.GUI.

At the beginning of the main region⁵¹ of the file, an App is initiated (which is actually a Qt app⁵²) with an instance of the previous class. Then, the window is rendered (using win.show()) and then displayed on the screen (using exe(), and both refer to the functions of the same name we discovered in Chapter 1 when we first met with the Qt framework).

In other words, both the description and the presentation are done; what is missing is the user interaction staff.

Responding to User Events

What you need to do now is to define an action to respond to every event you should trigger (those left empty, "", won’t be managed by the event system and are therefore totally idle). All that is required is providing the name of a function (or more precisely a method, although they are the same in Ring⁵⁴), because the code itself will be written later in the third interaction file. That method will be evoked by Ring (and, behind the scenes, by the main loop maintained internally by the Qt event management framework famously called Signals and Slots⁵⁵) at runtime as a response to the user event.

To do that, switch back to the Form Designer, select the only button you have on the form, and then set the setClickEvent property to calculateSum as a name for your method, as shown in Figure 3-17.

Once done, save the form, and verify that something changed in the sumCalculator.rform and sumCalculatorView.ring files.⁵⁶

As exposed previously in Figure 3-16 and described in the presentation file, sumCalculatorView.ring will delegate the execution flow to the interaction file, sumCaclulatorController.ring, where the calculateSum() method will be implemented (i.e., written in Ring) and executed.

Launch the application (Ctrl+F5) and watch the result, as shown in Figure 3-18.

You made it, but a better solution for displaying default values is to define them in the description file (in the Properties panel, by entering them in the Text property) and let the Form Designer generate them automatically in the presentation file. As general advice, let the controller (the interaction file) contain what is dynamic by nature. By “dynamic,” I mean the computations you need to make after something happened in the life of the program (a user or system event). The default values are rather static and can be provided before the program starts. Therefore, their best place is the model of our application (the description file).

In the Form Designer, select the two LineEdits, one by one, and enter 12 and then 8, respectively, in their Text attribute in the Properties panel. Save and run. It’s the same result as in Figure 3-18 but with a cleaner implementation.

What’s next? Writing the sumCalculate() method , in the same interaction file, to respond to the click event of the btnCalculateSum button.

Save the file (Ctrl+S) and then launch the form again. Click the Calculate Sum button. The result is computed and displayed in the lblResult text zone, as shown in Figure 3-19.

It’s working perfectly. Still the user interface design is far from being satisfactory. Let’s try a little enhancement.

Enhancing the User Experience

As a final result, Figure 3-20 shows your first GUI application in Ring.

Three Values of MVC in GUI Design

This separation of the three aspects of the GUI application (which I called description-presentation-interaction, for a good reason,⁶⁴ while they are better known in the software industry as the Model-View-Controller pattern) is essential to crafting a clean and agile software architecture. In particular, this helps achieve three strategic values of any modern piece of software: code reusability, code testability, and targeting of multiple platforms. Let’s discuss them, briefly, one by one.

Code Reusability

A beautiful illustration of how MVC empowers code reusability is when the same function we write in the controller layer (the interaction layer in our terms), calculateSum for example, can be used by many other widgets in our form. Want to practice?

If you were attentive enough while visualizing Figure 3-15, there was a bulb near the TextChanged event of the edtNumber1 LineEdit. This was planned for the practical example we will do now to show how the calculateSum method can be executed when the user changes any of the same two numbers on the screen, as shown in Figure 3-21.

To do this, go to the Form Designer and open the sumCalculator.rform file if it isn’t already there. Select the two widgets corresponding to the numbers, edtNumber1 and edtNumber2, one by one, and set their textChangedEvent properties to calculateSum, as shown in Figure 3-22.

Save and run and then test the form. While you are entering a number, the sum is live-calculated, and the lblResult label is updated! Congratulations, you’ve been reutilizing many times the same calculateSum function code you wrote only once!

Targeting of Multiple Platforms

Sorry, it is unavoidable! Whatever customer you are making a computer program for, or whatever software company you are working for as a programmer, you will need to make it runnable at least on desktop, mobile, and maybe web platforms. And if you don’t mind, let the mobile flavor work on both Android and macOS and on both small and large screens.

Armed with your Ring MVC arsenal, you can design a solution like Figure 3-23.

It’s always interesting when you have to deliver the “same” user interface to three different platforms: desktop, web, and mobile. They are completely different in regard to their underlined technologies. Still, portions of our code can remain the same and can remain multiplatform (shown in Figure 3-23). Hence, instantiating a text label "Hello!" at the position (32,52) of the screen can be interpreted in the same way⁶⁵ by a desktop window, a web browser, and a mobile screen.

On the other hand, there are some specificities of each platform in dealing with some graphic objects. Take the example of the Close button shown in Figure 3-23. While the desktop understands it and provokes the current window to be closed, there is no such a “closing” thing in a browser or on a mobile device. In fact, closing happens at the tab level in the browser, and this is not managed in principle by the web application context (it is a sovereign decision of the user who is free to close any tab independently from the application logic running inside the tab). While in a mobile device and if we cope with the Android application model, what you are allowed to do is to go back to the previous screen; that’s it.

Those differences represent hard problems well known by experienced developers. Based on the Ring user interface model generated for us, it is possible to manage them by making three different implementations of the view of our system (three versions of the sumCalculatorView.ring file) where we specify whether the close button should be rendered on each platform or not. All we need to do after that is call the correct version of the file depending on the user execution platform, using the system function we discovered earlier such as isAndroid(), isMacOS, isLinux(), and so on.

Ultimately, the true fruit of the SoC of three layers is that it allows us to change our technological choices, now or in the future, without breaking the whole application. If you find Ring tightly coupled to Qt as a GUI library while you are not comfortable with everything Qt, make another implementation of the sumCalculatorWinView.ring file with the graphic library of your choice. And if you are targeting the Web, then instead of using GuiLib, use the WebLib library and develop your user interface using the language of the Web.⁶⁶ Plug it in the system, and the system will work.

On the controller side, as shown in the figure, we could refactor our sumCalculatorController.ring file into two controllers: one for managing the events occurring in the desktop and mobile and one specialized in managing the web events. It is one possible solution, motivated by the similarities between desktop and mobile on one hand and the particularity of web interactions, managed in part on the front end using JavaScript, on the other hand.

Finally, on the model side, I decided to leave the same unique description file since the difference related to describing the Click event of the Close button can be dealt with, dynamically, in the Controller by doing the following:

• First, verifying the current platform (using the same isAndroid()-like instruction)

• Second, routing the execution to a dedicated flavor of the close() function written specifically for Android phones (android_goback(), for example)

I won’t show it in code this time, because we don’t have enough space. In the next section, however, you’ll learn how to get data from text files, while designing a clean data acquisition architecture in code since there is no tool similar to the Form Designer that does it for us.

Reading Data from a Text File

Population (POP) is measured in million people, population growth (GRO) is measured in percent per year, median age (MED) is measured in years, and population density (DEN) is measured in people per km.² The data is taken from Wolfram|Alfa, which compiled it from The World Factbook of the United States Central Intelligence Agency.⁶⁸

Specifying the NorthAfrica App

Awesome bar chart, isn’t it?

Seven Steps to the NorthAfrica App

Creating Conventions and Configuration Files

Now we will start step 2 listed in the “Seven Steps to the NorthAfrica App” section.

Now for step 3 of the steps listed in the “Seven Steps to the NorthAfrica App” section.

Name it config.txt and save it in the same NorthAfricaApp folder we are working in.

Transforming Text Data into a Ring List

Now for step 4 of the steps listed in the “Seven Steps to the NorthAfrica App” section.

We’re doing good.

Preparing Data for Showing a Graph

Now for step 5 of the steps listed in the “Seven Steps to the NorthAfrica App” section.

What we need now is to prepare the datagraphs for our charts. Wondering what these “datagraphs” are? How do they differ from the dataset we have in our aData list? And why do we need them? All good questions.

To explain the point, let’s consider the Excel sheet shown in Figure 3-24 containing the same dataset and a bar chart based on the horizontal chart we want to make.

In Excel, it’s live and happens like magic. But under the hood it takes a long way to get from the data sheet to the visual graph. Indeed, Excel thinks of the x and y axes, the scope of values they will represent (from min to max), how many steps they contain, and what the length is of each step. Then Excel calculates the height of every bar depending on the ratio between the value of the variable and the total length of the axis. Finally, it organizes all this data in a matrix directly consumed by the graph: the matrix is the datagraph. I told you it was a lot of work!

If the datagraph matrix is done, then the graph is easy to render. The matrix is somehow an invisible layer on top of the graph itself. In its simplest form, every cell is either 0 or 1. Visually speaking, Figure 3-25 shows what I mean.

In our case, the y axis will span from 0 to 100, subdivided into 10 steps. Therefore, y_i, the y coordinate of the variable i, is obtained by applying this simple formula:

where i ∈ {MAU, MOR, ALG, TUN, EGY}.

Thus, the matrix of the horizontal graph can be easily concluded, as shown in Figure 3-26.

The datagraph of the horizontal chart can be obtained by simply turning the previous matrix to the right, so we get Figure 3-27.

Let’s write an algorithm to reproduce this case in Ring. We start from the lists instantiated dynamically by the transformer. We consider only the first variable (Population), and we end up with only one of the two datagraphs, the horizontal one.⁷⁰

After testing the result, comment out the lines containing the output to the screen using the ? keyword; we no longer need them. We can use the same logic for the remaining variables (population growth, median age, and population density). I will learn it for you as homework. For the moment, we can congratulate ourselves for accomplishing step 6 of our script. What remains is to show the bar chart. For that, we program the chart-rendering feature in a new chartRenderer.ring file.

Rendering the Graph Inside a Text String

Now for step 6 of the seven steps we’re working on.

As requested at the end of the previous section, create a new file called chartRenderer.ring in the same working folder of NorthAfricaApp.

If everything is done right, then what you see in the output window when you run the chartRenderer.ring program will look like Figure 3-28.

What about the second chart, the horizontal one? Well, it requires another version of chartRenderer.ring and may be another version of datagraph.ring. It depends on the strategy you adopt and the level of SoC⁷³ you adhere to. But, in all cases, the initial data in data.txt remains the same. The transformer.ring file also remains the same whatever graph you want to design. And if you need a version of a given bar chart for a specific platform, a smartphone for example, then only one file must be changed: chartRenderer.ring. Things are crystal clear; you are just rendering the same chart to a different platform. Other programmers who are fond of the Tunisian shakshuka⁷⁴ may change everything they did and start from scratch. But you, no, because you’ve done it, you’ve “committed” your first clean design in Ring!

What if you make this second horizontal chart by yourself? You will gain a lot of knowledge while trying even when (and mainly when) you don’t succeed.

Now we move to another strategic type of input you should have in your skillset of programming in Ring: inputs from a database.

Connecting to a SQLite Database

Excellent. It is sufficient now to verify that it works. We will come back to aResult in “Adapting the Connector to the Database” to understand its structure and see whether it needs some help to cope with the format we agreed on for the datagraph. Now, using both text and a database to feed the graph invites us to reflect on the architecture of the NorthAfricaApp.

Designing a Clean Data Acquisition Architecture

Before we go further, there is a design reflection we need to make about the overall architecture of our NorthAfricaApp . To show the point, let’s craft a visual representation reflecting what we have done until now, as shown in Figure 3-29.

Our system begins with a data hosted in a structured text file, which is transformed to a native Ring List to make it programmable. Then we compute that data into a matrix (datagraph) to prepare it for rendering without hassle. Finally, the matrix is parsed and rendered in a bar chart contained in a native Ring String. The string is shown on the screen.

Despite its clarity, Figure 3-29 shows the most important value of our architecture: reusability and ease of extension. Indeed, with the system we designed, as I said before, making new graphs (a pie chart or a comparative bar chart, for example) won’t require⁷⁶ more than providing a new datagraph with a new renderer (while reusing the same data source and the same transformer). At the same time, adapting a given graph to different platforms can be done by providing a specific renderer for each platform (while reusing the same datagraph, transformer, and data source). Such gains are better represented if the visual is modified to look like Figure 3-30.

At the bottom in the figure, in particular, the same datagraph.ring file has been used to render a bar chart in two different platforms, a web browser and a mobile phone. In real-world projects, this decision can be motivated by the fact that the rendering technology used on both platforms is the same: a cross-platform web engine, like WebKit,⁷⁷ for example (on which Qt WebView and by consequence the Ring Form Designer WebView widget are based) running on a desktop and also on mobile devices.⁷⁸

What we are concerned with in this chapter, however, is data input, so let’s stay focused on achieving extensibility on the left side of the architecture and not on its right side. Next, we implement the feature of switching between a text data source and a database data source without impacting the whole system we have built so far.

Switching Between Text and Database Data Sources

Take a deep breath; now we are tackling step 7 of our seven-step exercise. In a minute we will be harvesting the fruits of all of our labor in the chapter.

Our bar chart should be there with the same data displayed on the screen, but coming this time from a database and not a text file and without being impacted by the fundamental change of data source we’ve just made. Think about it for a while: how exactly can we make it happen?

Well, many answers are possible. The one that first comes to my mind is to adapt the first three lines of transformer.ring by removing the code responsible for connecting a text file and replacing it with code connecting to a database. This means that a transformer must be written to every data source. You can go for it, but one can argue that there will be a cost. Think of the situation where your system contains 30 transformers for 10 different data sources and the logic of transformation itself needs to be changed. Your cost can be devided by 10⁷⁹ if you had only one place that does transformation independently from the data source. Right?

An intermediate node between the data source and the transformer would then be necessary. I’ll call it the universal data connector; it’s the code that effectively connects to a data source, whatever this data source is, and delivers an abstract data format to the transformer whose job is transformation. Visually speaking, the whole system architecture would look like Figure 3-31.

Without delay, let’s experiment with this design option by implementing a universal data connector in Ring.

Implementing a Universal Data Connector

The first thing we should do is to go back to transformer.ring and see how we can refactor it so the specific part of connecting to a text data source, indicated as (1) in Figure 3-32, is separated from the part of transformation itself (2).

For the separation to be effective, a particular focus should be put on the zone in between (3). In fact, this zone stimulates us to ask an important question: what is the intermediary data that format zone (2) needs to be fed so it does its job without caring about how zone (1) is working?

We went back to these details because it is always useful to develop a memorable mental model of the system in hand before you undertake any refactoring that impacts its structure. In particular, the first criteria of a successful separation of concerns, like the one we are planning to make here, is to get the same result as before while enhancing the organization of the program parts.

Another thing you should always remember is the goal of the refactoring project itself, expressed in terms of the value you will gain. This is easy to lose, like a needle in a haystack, owing to the throng of technical details and sometimes because of feelings of anxiety and puzzling frustration. In our case, the refactoring is made to allow us to diversify our data sources while keeping untouched the same chain of operations coming after the connection staff: transformation and rendering of the final chart.

Figure 3-33 summarizes where we are and what we should do.

Save it in the same NorthAfricaApp folder . From the original transformer.ring file, ensure that the // Preparations part formed from the first three lines was deleted and save the file as is with the same name. Now the transformer contains just the remaining code, which is really responsible for the transformation job.

To test the system, add a load connector.ring line at the beginning of transformer.ring and then go to chartrenderer.ring and execute it (Ctrl+F5). As shown in the output window, our bar chart, safe and sound, salutes us again.

Adapting the Connector to the Database

It seems like we achieved our goal, but we didn’t. Remember that the separation has been made to support other types of connections like a database. So, let’s verify whether the data structure returned by the database connection obeys the same format returned by the connection to the text file.

Some data format unification work is then necessary!

Unifying the Data Format Delivered by the Connector

Visually speaking, Figure 3-34 shows what we need to do.

Save this dbconnector.ring file in the NorthAfricaApp folder. At the same time, go back to the connector.ring file and rename it as txtconnector.ring . In the NorthAfricaApp folder, physically delete the connector.ring file since we no longer need it. Also, in the same folder, delete the binary file of the SqlLite database, northafrica.db, so we can restart the chain on a clean base.

Tired? I understand. Now we can test everything and see whether the work done about the seventh and last point in the solution script we agreed on at the beginning of the section will be rewarding.

Testing Our Data Acquisition Architecture

You know what? We have reached step 7 in our plan for our refactoring project!

The bar chart is displayed without structurally changing any file in our pipeline other than specifying the good connection file in transformer.ring. We didn’t even touch the datagraph.ring and chartRenderer.ring files. That is awesome, except there’s one little detail: the final refinement.