Some knowledge of PHP is becoming a requirement for the debonair, sophisticated, man-about-town RPG programmer.

Welcome to the second installment about PHP. Nobody can dispute that PHP has become very important in the RPG world for providing Web access support for our new and existing RPG applications.

In the last installment, we reviewed some very basic facts about PHP—things you might want to know but would be hesitant to ask about on a first date. We want to continue that exploration in this installment by looking at what incorporating PHP will do to your normal routine.  

PHP and RPG Differences

One of the big differences between RPG and PHP is, in my opinion, that RPG is a full-featured language and PHP is not.

That is, if I'm using RPG, I can do everything with that one language; read files, update files, do calcs, have ridiculously complex "if" statements, print data, display data on a screen, whatever I feel like.

Now that's not to say that PHP is a one-trick pony. I can read and update files, including DB2 files (that is, something other than just MySQL), I can set up "if" statements, I can define arrays and hold data in them for manipulation. And, of course, I can display data in a GUI format. There's no doubt, however, that the display part of the language is it's raison d'etre, and everything else is just there to help support that.

And my point is? The point is that we'll need to adjust how we think about building an application if we're going to use PHP as part of the equation. And that brings up an interesting point.

Why Use PHP Instead of RPG?

Of course, a fair question might be, Why bother with PHP at all? I'm not saying to not do GUI and to just stay on green-screen, but rather why do the Web side of things with PHP? There are a number of ways to do the GUI, the two most common for i people being CGIDEV2 and PHP.

CGIDEV2 is a wrapper that allows you to incorporate CGI APIs into your RPG programs. Because it's RPG based (that is, because the resultant application is all RPG based), it can be an alternative to PHP. Both are fairly easy to learn (compared to RPG or Java). Both use HTML, CSS3, and JavaScript to set up the Web pages. And both provide easy access to the data held on the IBM i. The truth is, there's no overwhelming reason for using PHP, but there are a couple of good reasons that I think are worth paying attention to.

First, PHP is really designed and built to display and modify Web pages. That's its main function and its only reason for existing.

Second, if I want to start fooling around with CGIDEV2, I need access to an i. With PHP, I can start learning right on my PC since PHP can be used without the i.

Third, there are a lot of people out there who already know PHP and who can be brought in quickly, educated on the i as needed, and start right in coding good PHP. The same also goes for educational materials, sample programs, and frameworks; there's much more out there to support PHP than there is CGIDEV2.

Fourth, PHP has some very advanced array functionality that can be very helpful when you're dealing with record-level information.

Fifth, and maybe most importantly, PHP has object-oriented functionality. That is, many of the PHP solutions that you see use OO classes as the basis for their functionality. Normally, most RPG programmers aren't exposed to object orientation without being infected by Java, but PHP does have some OO functionality and it's probably more accessible than the stuff in Java. So getting some exposure to the language and its OO components is a definite plus for the average PRGer.

On the negative side, full use of PHP (that is, using it in an enterprise fashion) will pretty much require you to purchase the Zend products (you can get started for free), but that's balanced by the fact that for large sites, PHP scales easier than CGIDEV2.

By all accounts, it's a close call, and you may want to use both, but I'm writing about PHP and so will stick to that.

From Mega Programs to Modules

It's my opinion, backed up by absolutely no real data, just my experience in working with clients over the years, that the overwhelming majority of RPG programmers write monolithic programs. That is, everything that they need to do is done within a single program. Some of them are just large, some are truly monstrous, and a few violate everything that nature tells us about what is good and decent. They may not be as big as they were five or ten years ago, but they're still not modular.

I'm not trying to be hard core here; I've developed a few of these fellows myself over the years. It seems to make sense: put everything in one spot so it's easy to get to. Unfortunately, it never works out that way. While you, the author, may understand the whole mess, it's very unlikely that anyone else can just step in in the event of your unforeseen incapacitation/death/incarceration and take over.

It may not be fair or whatever, but my opinion is that the level of professionalism that you have is directly proportional to your desire to develop modular programs. Back in my youth, when I was a COBOL programmer, everything I wrote was modular. No, seriously, it was. Yeah, in COBOL. We used the Model-View-Controller (MVC) model before it had a name, and one of the reasons I resisted switching to RPG for almost two years when we bought a 400 was because of the lack of modular support. Now, however, with /Free and the CALLP prototyping, there's no reason not to go modular. In the words of Angus Young, modular programming "makes good, good sense."

But if you're going to use PHP and RPG, then you pretty much have to use modular programs, don't you? And to be honest, I consider that a major plus in terms of using PHP.

The MVC construct seems to be the most prominent modular model in use today. It consists of three module types: model (logic), view (display), and controller (getting in, getting out, moving from one module to another). The beauty of this option is threefold: first, separating the code into small bundles that are more easily understood; second, grouping like code elements together; and third, allowing each module to be coded in the language that's most appropriate for its needs. Of course, doing modular programming requires a couple things of the developers.

First, they need to think about what they're going to do. For most people, writing a large program starts by figuring out what the driver file is going to be and setting up a loop that will read through the required records for that file. After that, all of the code just happens.

Second, it's a little harder when you're going to do a modular project because you need to think about the flow of the application and what will go together in the individual modules. It's not like rocket science or what choreographers go through setting up one of those dances for Dancing with the Stars, but it requires a little more thought than just bulling your way through a monolithic program, thinking as you go. So you want to start by thinking about what control moves you're going to have, what display options there are, and what logic will be required. Then you build the modules for each of those using whatever language is most appropriate.

PHP- or RPG-Centric Design?

Do you want your application to be PHP-centric, starting with a PHP page (an HTML document with PHP code or a straight PHP document), or are you going to make it an RPG-dominated application with PHP called in only to handle the screen access?

You can go either way, of course, but you can make an intelligent choice. One way to decide is to look at your starting point. If you're starting from scratch, with a new application, then you may want to make the PHP pages the center point and call RPG programs that are required to edit the data. Or, if you're updating an existing app, then you'll probably want it to stay RPG-centric and just bring in PHP when you need to display the screens.

Another Option

But there's another way to look at it. Start by taking a look at the application. Is this data-entry oriented? Is it primarily about taking in data and then editing and possibly modifying it before it's written to a file on the server (the i) that you are currently on? If so, then using a PHP-oriented function and calling RPG edit modules might be the best bet.

If, however, the application is primarily processing-oriented, with heavy IO and lots of editing but not a lot of display, then you probably want to make it RPG-centric and bring in PHP only as needed for the screens to kick off and close the application.

By looking at the application function, at what it's supposed to do, you can get a good feel for which programming language should take the lead and which should be the follower.

The Next Step

The next step, of course, is to actually be able to do the link from an RPG program to a PHP page and vice versa. And that's exactly what we'll discuss in the next exciting installment of this series.

David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by phone at (616) 304-2466.

---

MC Press books written by David Shirey available now on the MC Press Bookstore.

		21st Century RPG: /Free, ILE, and MVC Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods. List Price $69.95 Now On Sale

Also Read

Advanced/Free - Function Calls and Return Values

PRACTICAL ILE - ILE Service Programs

Data-Manipulation Operations Using Free Format, Part Two