Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

EGL Rich UI on IBM i: Do you Dojo?

Taking advantage of the Rich UI features of EGL architecture on the AS/400 can save you time and complexity. Rich internet applications can be difficult to write, even with Java and Webspher. EGL eliminates the need for programmers to learn JavaScript, XML or REST and Java or PHP. Using Dojo can make everything even easier with Rich UI to take away some of the usual programming work.

5250 may be best data entry interface ever invented, but if you want applications that sizzle, the green screen...

isn't exactly the tool of choice. Although alternatives exist, the browser has become the interface of choice for business applications. And with the advent of Rich UI frameworks, the browser is arguably one of the best interfaces available. With Rich UI, you get applications that look like this:

Click on image for larger version

Unfortunately, Rich UI comes with a price tag: the more full-featured the framework, the more you need to learn to take advantage of those features. Unless, of course, you use EGL!

Are rich internet applications hard to write?
It depends on your definition of "hard". Subfiles are hard. But one thing is for sure, rich internet applications (RIAs) have far more moving pieces than a standard green-screen application. Remember, RIAs are by definition multi-tiered applications. At least part of the code (usually the user interface logic) runs on the client machine. With JavaScript frameworks (the focus of this article), that code runs in the browser. At the same time, part of the application runs on the host. Typically this is your business logic, and it is exposed to the client via some sort of Web service protocol. So you need an architecture that looks like this:

Click on image for larger version

Note the various layers. If like me you're primarily an RPG programmer, then the far right side of the diagram is simple enough. But after that it gets tricky quickly. No matter what you choose, you will need to define the messages that the Web services use, and even that decision is a difficult one. This is why there are two boxes in the service column. REST is faster than SOAP, but SOAP is more widely supported by tool vendors.

EGL and Dojo info
EGL Cafe opens virtual doors to IBM i programmers

Application modernization for AS/400

Webcast: Dojo fundamentals

One option to consider is Java and WebSphere. Java has classes that will allow you to expose a Web service, and other classes that will allow you to call RPG programs, convert between EBCDIC and Unicode, format the Unicode as an XML stream (for SOAP) or a JSON stream (for REST). The primary problem is that you have to become quite the Java programmer to be able to handle all of that. And even then, you're not done, because now you have to write the code in the far left column. Now you have to move from Java to JavaScript and start writing your rich client. You can try to build a set of widgets yourself, though I don't think anybody would recommend that approach. Instead, you need to learn a framework such as jQuery or Dojo or YUI. A good comparison of some of the frameworks can be found at the SlickSpeed website.

Other options exist. You can use a simple scripting language such as RPG-CGI or PHP to replace the Java portion, but really that's just delaying the inevitable, because eventually you have to write the JavaScript code. And with a scripting language, you have to generate the JavaScript code in the scripting language: in effect, you'll be using RPG to write HTML to generate JavaScript code on the fly. Or even worse, you'll have to learn to use PHP to call RPG to get data to format HTML to generate JavaScript on the fly. The complexity bar just keeps getting higher.

The EGL architecture
EGL uses a single, simple syntax to build all tiers of a multi-tiered application. Instead of learning JavaScript, XML or REST and Java or PHP, with EGL you only learn one new syntax: EGL. The architecture is much simpler:

Click on image for larger version

Note that the boxes are basically the same, except that all of the non-ILE code is written in EGL. What happens is that you write a library function in EGL which uses a call opcode to invoke your business logic. You pass the library function an EGL record and it calls the RPG program to fill the record (or process the record if this is an update). You create a service part that exposes that function as either SOAP or REST (or both). Exposing a service is literally a pushbutton process.

Once that's done, you write the rich client. I always recommend using REST to communicate between the rich UI and the service; it's leaner and easier to use in my opinion. You simply right-click on the service part in the middle tier and then tell the tool to create an interface part in the Rich UI tier. The ability to do that is one of the highlights of the integrated nature of EGL.

In the figure, the middle tier (the light blue boxes) are part of a standard EGL Web project, while the yellow Rich UI box is an EGL Rich UI project. What I love about this is that all of the projects live in the same workspace, and I can easily go back and forth between them with the EGL tooling. Even more cool, is the fact that I can edit, compile and debug the green box (the ILE business logic), from the same RDi-SOA workbench! It's easy to underestimate how much of a benefit it is to never have to jump between different tools to develop a complex multi-tiered application.

Also, the development is very visual. The screen you saw in the first page is exactly the same whether you are running it in an external browser or in the preview mode of the rich UI designer.

GUIs for nothing, apps for free
Well not quite, but one important thing is that when you use this architecture, you also get several other options. Your encapsulated ILE logic can be used to write green-screen apps (still important in many shops), the library functions can be directly called by the thin-client EGL tooling, and the services can be exposed to other units within the company or even business partners.

The extended architecture looks like this:

Click on image for larger version

None of it requires much additional work, and most of your core code is reused. This is one of the reasons that EGL is so appealing in a mixed interface SOA environment.

On to Dojo
All of this has been leading up to creating code with Dojo. Let me now show you a few example of creating code with Dojo. Let's take the radio buttons on the bottom of the graph. There were two buttons, "Gross Sales" and "vs Forecast". The "rapid application development" layout for this is quite simple:

salesOptions Box { alignment = 1, children = [
  new DojoRadioButton,
 new TextLabel { text = "Gross Sales", paddingRight = 12 },
  new DojoRadioButton { selected = true },
 new TextLabel { text = "vs Forecast" }
 ] };

At the highest level, you specify an element of type box. A box is the basic unit of all EGL Rich UI design, and it represents an HTML table. In the table, you can then specify rows and columns. Without getting into too much detail, the code above creates a "display-only" version of the two radio buttons and their associated text.

To give you a little idea of how Rich UI is designed to make your life easier, let me explain a couple of the keywords. For example, the alignment = 1 clause is what centers the entire box underneath the graph; you can align boxes left, right or center. Next, in order to get a little gap between the two buttons, I also specified paddingRight = 12 on the Gross Sales text label.

You can do an even more fine-grained layout using cascading style sheets (CSS). Any element in the entire UI can be assigned one or more CSS classes, and then you can use those classes to apply all manner of attributes, from fonts to colors to backgrounds to positioning.

Note that I said "read-only." The graph is hardcoded to the "vs Forecast" data, which is in itself hardcoded. The buttons are shown, but don't click. This is the sort of thing you'd use to get user signoff on the basic layout of the screen. And it's very easy to do. Let's take a look at the graph itself:

salesGraph DojoBarGraph { isColumnGraph = true, data = dataVs };
 dataVs int [] = [ 102, 35, -40, 25 ];
 dataGross int [] = [ 255, 160, 30, 75 ];

Creating the graph is literally one line of EGL code. Creating the dummy data is another line. You may have noticed, though, that I included a third line, the dataGross array. That's because the last thing I'm going to show you here is just how easy it is to connect actions to your widgets with EGL Rich UI.

Making Dojo work
Let's take something that can be a bit of work even for a savvy Web designer. In this case, I want to toggle between the two datasets, dataVs and dataGross, depending on which radio button has been selected. That requires two two-line functions and two minor modifications to the options box we saw earlier.

First, the change to the box. Each radio button will now have an "onClick" handler assigned to it. That is a function that will be invoked when the radio button is clicked.

salesOptions Box { alignment = 1, children = [
  new DojoRadioButton { onClick ::= doGross },
 new TextLabel { text = "Gross Sales", paddingRight = 12 },
  new DojoRadioButton { selected = true, onClick ::= doVs },
 new TextLabel { text = "vs Forecast" }
 ] };

The first button will call the function doGross, while the second button will call doVs. The code for those functions follows:

function doVs(e event in)
  salesGraph.data = dataVs;
 function doGross(e event in)
  salesGraph.data = dataGross;

This is very simple stuff. Simply set the data member of the graph to the appropriate array and then tell the graph to re-render itself. That's all there is to it. If you re-run the application, you can click on the radio buttons to switch between Gross Sales and vs Forecast. That's all it takes to enable the UI.

Note that I can use hardcoded data for testing purposes and more importantly, it's very easy to set up that data. That allows me a lot of flexibility when it comes to testing, especially testing unusual data cases. The next steps would be to write small library functions that return the data arrays, and then eventually connect those to services on the host. But with this simple code, I can put the UI in front of the end users and get immediate feedback.

The EGL Rich UI tooling is just coming of age, but already it shows great promise. I invite you to visit the EGL Cafe to begin your exploration into this new tool set. You can find quite a lot of information on the tool, forums where the language is discussed, and even links to download trial copies of the components of RDi-SOA.

Go forth and be GUI!

ABOUT THE AUTHOR: Joe Pluta is the founder and chief architect of Pluta Brothers Design Inc. Joe uses the Rational tool suite extensively, and is on the beta teams for most of its i-related products. He performs onsite mentoring and speaks at user groups around the country. You can email Joe with questions.

This was last published in May 2009

Dig Deeper on iSeries application development tools

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.