I can't think of a better title for this, but since I hope this becomes an ongoing series of posts, I want to make sure I stick a number in there. Maybe I should have made this one Number 0, because it's going to be sort of an introductory post, but that's okay.

This blog series will be based on things I find as I'm writing RUI applications. It will range from little things like tips for formatting (using a class to right-adjust grid columns) to major RUI topics such as how to implement services in a modular architecture (the answer is Delegates, but the devil is in the details).

Because of the book, I've already got a list of topics on hand. In fact, as I write the blog posts you'll get more glimpses into the book writing process. But I can give you a few quick previews. For example, I'm becoming pretty proficient at formatting Grids. This is important stuff for those of us in the i community; the Grid is the replacement for the subfile and it's crucial to being able to build applications quickly.

Another thing that comes into play is the fact that all the HTML for a RUI page is generated at runtime. Because of that, it's difficult to see the actual HTML which in turn makes it hard to diagnose CSS issues. I've figured out a way around that. I hope to make a generalized widget available soon, but I will at the very least post some example code. The trick is outerHTML...

Anyway, I'll be back posting more. Let me know if there are areas you need addressed.

Joe

I noticed that I have been somewhat remiss in that I haven't actually written a formal "Welcome to my Blog" post. This is my first blog, so perhaps you can forgive me that transgression. (I told my good friend David that I had finally releneted and was blogging. His response? "I AM LOCUTUS OF BLOG! YOU WILL BE ASSIMILATED! RESISTANCE IS FUTILE!" Guess he's right.) Anyway, it's that time - time where I try to let you know what this corner of the Internet is intended to be about, and you can decide whether you want to follow the bouncing blogger.

I have a very straightforward goal. I want the i platform to continue on being the best darned business logic server ever designed, and EGL is the way to do it. The reason is simple: the IBM i, whatever it's name or incarnation, has always been about simplicity. You could, with enough work, get another platform to do most of what the i does. But it was always easier, and faster, and more productive with the i. Not only that, but until the advent of the Web, the i was perhaps the last bastion of the one-person IT shop; one good programmer could literally do everything required to keep an i shop running. If you knew DDS, CL and RPG (or COBOL), and knew how to hit F1 and F4, you could pretty much run an i and keep its users happy.

However, in the brave new world of Web development, the i message got a little fragmented. Rather than there being a single path to getting your work done, there were many. RPG-CGI, Net.Data, Java, and now even PHP; these were all heralded at one time or another as the way to the web for i shops, but for one reason or another, they never lived up to the hype. It seemed that the technology was either easy to use but a little out-of-date, or else so bleeding edge that developers couldn't keep up. In either case, the i slipped further behind the curve and we know the outcome: it became that "old" box in the corner that just wasn't glitzy enough. Forget that it had been running all applicaitons flawlessly and with nearly zero downtime for years; the new generation is all about the glitz, and what have you done for me lately.

Enter EGL! By combining a procedural syntax with the concept of hiding complexity, EGL does what i developers have been asking for: it gives them a clean, consistent way to write web applications where they can concentrate on the business logic rather than the plumbing. In many ways, EGL is the spiritual successor to the 5250. While it far surpasses the 5250 in rich user experience, in many ways it's as easy, if not easier, to use than the old green screen SDA. Combine that with a carefully crafted and deceptively simple CALL Interface, and EGL does for the web what display files did for the green screen.

There's a subplot here: using EGL and RPG together. Note that I said RPG; you could also use COBOL if you were so inclined, and lots of EGL folks do. In fact, EGL will generate COBOL and I will spend some time with that particular piece of the technology over the coming months. But I am an i guy, and for the majority of us, RPG is the language we use to code business logic. And while there are lots of really super-bright people working to make EGL a complete, self-contained business language, my particular self-appointed niche is going to be making sure that all those RPG programs (and more importantly, those RPG programmers) can use EGL to enhance and extend their existing applications, letting them co-exist with brand new applications (written in EGL, of course!).

Programmers may some day be able to write entire ERP applications using nothing but EGL; that's certainly the goal of the EGL team. But for now, i shops already have business logic - logic that they've spent years (even decades!) developing - and the best initial use of EGL in those shops is exposing that logic, either directly as browser-based web applications or - moving to the true SOA approach - as web services that can be consumed by other internal and external clients. Then, they can combine that newly enabled business logic with all the rich application features of EGL to create new integrated applications they never dreamed of.

And my goal will be to explain how to do that quickly and productively.