Re: RPG UI Frameworks was->RE: Fw: Enhancements to RPG -- RPG400-L

I read in the Business section of this morning's paper that IBM was going to start putting the PS3 chip on "mainframes." No specifics as top what mainframes meant, could be just the zSeries, could include the i and, even, p.

The PS3 chip is the one that IBM and Sony developed for kick butt graphics on the Playstation. Not being a double E myself, I'm not sure what the actual implications for the UI on the System i5 might be. But with the myriad of assaults (under the radar for the most part) by IBM on M$ turf, I wouldn't be surprised if this was another one in some form or fashion.

Or maybe it's just a graphics card.

* Jerry C. Adams
*IBM System i5/iSeries Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>

Bob Cozzi wrote:

Aaron,
Believe me, I've been a proponent of GUI with RPG for decades. Believe me, I
drank that Kool-Aid long before you learned to drive. I welcome you to the
on-going battle. To me, Web/Browser interfaces via CGILIB or others are the
closest we've come to a great RPG GUI so far. The guys at eXport Ventures did a
great graphical, event driven RPG user interface years ago--but it didn't take
off very much.

Most of this event-driven stuff really needs an OS that can handle dispatching
the event messages. Certainly OS/400 can do that, but it doesn't. However, a Web/Browser interface can already do event-driven stuff via AJAX and
regular CGI calls to RPG or any language. What would be beneficial is the
ability to "AJAX to" a subprocedure directly rather than only to a program. I'm
not certain if that's much better from a performance standpoint than just
leaving a CGI program active in its A/G and reactivating it, but it would be
cooler. :)

-Bob Cozzi
www.i5PodCast.com
Ask your manager to watch i5 TV

-----Original Message-----
From: rpg400-l-bounces+bob=rpgworld.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+bob=rpgworld.com@xxxxxxxxxxxx] On Behalf Of albartell
Sent: Thursday, April 26, 2007 8:04 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RPG UI Frameworks was->RE: Fw: Enhancements to RPG

<Cozzi said>Class (5) items are similar to class (3) items in their
importance. Sure it would be cool to have, for example, integrated CGI/Web
built-in functions in RPG IV, but that would have been important in 1998, or
2002 or 2004 or 2006. In 2008 and beyond it is sort of like adding Pointer
Support to CL in 2006. Why do I care? I've already coded all the CL I'm ever
going to code. By 2008 or 2009 I've already written tons of CGI/Web stuff
using xTools, CGIDEV2, or Brad's eRPG library or even using the CGI APIs so
why would I care? (CGI/RPG is just an metaphor here.)

<Aaron responds with>
Bob, I don't think you are recognizing the significance of why people are
leaving in droves off of the iSeries. They aren't leaving because RPG is a
bad business logic language. They aren't leaving because the iSeries is an
unstable platform. Many are leaving because of look and feel - plain and
simple. The cost to get to that new look and feel on the iSeries is simply
more expensive than going to .NET (at least initially).

The reality of the matter is that most, if not all, of the CGIDEV2
equivalents out there are simply one step above doing raw CGI. If I had not
worked with frameworks in PHP and Java then I would be standing right next
to you with what you are saying, but there is a lot to be said about a solid
and easy to use Web/GUI thick client framework. Having to write less
plumbing saves a lot of time (i.e. look at CHAIN vs. SQL single record
SELECT).
As I said in another post awhile back, RPG is fairly well suited for an
event driven UI framework because of procedure pointers and callback
capabilities. Just think if there was an RPG "router" program that front
ended your RPG program that had business logic and screen flow code. Every
time an event (e.g. specific customer selected from an HTML table) occurred
it would send the current form to the RPG router program on the server. The
router program would then gain entry into your RPG program by way of
procedure pointer (see example code below).

D cust_listselect_event... D PI
D pSessUId 15P 0 Value
D pEvtTyp 10 Value
D pUIObjNam 50 Value

D cstNum s 10u 0
/free

cstNum = RPGUI_getSelectedRowUnqId(pSessUId);
RPGUI_addControllerParm('EditCust': cstNum); // Priming next screens
input values
RPGUI_displayScreen('EditCust');

/end-free

I am debating whether to pursue that thought with a full prototype. Does
anybody else see the potential that I am seeing?

Aaron Bartell
http://mowyourlawn.com