Re: Modernizing Green Screen Was: Re: IBM HATS vs. ? -- WEB400

Here's an idea...
Why try to keep up with the rest of the world?Instead let's make a leap forward, and forget about web 2.0 and http.
Use Google Wave as a platform to implement a modern UI.
A wave, then, is a session, or a conversation between a (RPG) program and a user.
To do this, three things are needed:
1) Define a wave structure (XML) which specifies the state of a UI (like views, buttons, entry-fields etc).
2) Create one or more "gadgets" to present this UI.
3) Create a serviceprogram so that a program can act as a "robot" that manipulates the wave (i.e. it manipulates the UI).

The implementation has the same architecture as with our green screens. I.e. NOT client/server.It takes advantage of the unique capabilities of the IBM i, i.e. managing thousands of (interactive) jobs easily.Each job may connect to one or more waves (i.e. sessions).The program or robot is not called from a client, but "acts" on it's own, like it currently does with green screen.The program may register procedures to be called after specific UI events (like button click).But the program may also just write out a "screen", wait for input (i.e. wait for a specific event), and continue processing.In other words, the RPG "main" code, is the "event processing" loop, with the possibility to do something else then just read and dispatch events (like normal GUI program). So we have a procedure like "ProcessAllEvents" which processes (read/dispatch) alle events in the queue and when done continues processing. Or "WaitForEvent" which waits until there is at least one event in the queue, and "ProcessEvent" which processes the next event in the queue if any, etc etc. You get the picture.
Btw, i don't have the time...
Any takers??

Date: Tue, 6 Oct 2009 16:01:28 -0700
From: jrperkinsjr@xxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Modernizing Green Screen Was: Re: IBM HATS vs. ?

Joe,
In an ideal world I would use JSF/Facelets (or Wicket maybe) on top of JPA
or Data Queues to get and transmit the data. Maybe even web services or SOA
to transmit the data. I would keep the back-end in RPG for the business
logic. Thinking out loud I wonder if it would be worth creating a library
that would allow to use annotations on POJO's for Data Queue entries...

Anyway...

I know the mindset of most programmers (or at least ones I talk to) needs to
change. I don't think the green screen will/should go away, but the business
logic needs to be written in a MUCH more modular fashion.

I don't think a XML interpretation of the 5250 data stream is the be all end
all, but to me it's MUCH better than a screen scrapper. It forces the
programmer to at least a think a little more modular. I would hope at least.
In fact you are convincing me it might not even be worth it at all.

In the end there are numerous ways to handle all this stuff. I personally
think the best result is redesign the UI from scratch. Sometimes that means
you have a lot of business logic to change too (actually usually just
separate), but I feel it's got to happen at some point. For every day you
don't you're probably a week or two behind the technology.

I don't work for an ERP vendor, so I'm sure that my employer will not let me
write a new UI for the one we sell. We do however sell a web package that is
in desperate need of a make over. I'm constantly trying to get them to move
to newer technologies than code that was written for Java 1.2. It completely
suffers from an old-style-RPG feel even though it's Java and JSP. Wait...
...are JSP's the DDS of Java?

This is completely my opinion and ramblings. Sorry if I'm ranting too much,
I'm actually dealing with our web solution now, <sigh>.

Oh, and yes I still need to check out EGL. I know you are a proponent of it,
but I know my company won't go for that.

--
James R. Perkins
http://twitter.com/the_jamezp

On Tue, Oct 6, 2009 at 15:05, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:

The primary problem with moving from green screen to web is the
impedance mismatch. RPG applications are a page at a time, and most RPG
programmers think that way and thus most tools follow that path. And if
you use Web 1.0 thin-client designs you can match up relatively
closely. Some of the more sophisticated tools allow you to merge
multiple green screens into one page, but at the end of the day you end
up writing applications that are very much web counterparts of green
screen: a table rather than a subfile, a form rather than a record format.

If you're willing to go this route, JavaServer Faces (JSF) is very
powerful and allows you to avoid a lot of the plumbing. Tools such as
those from Rational make it even easier.

But if you want real Web 2.0 applications (the ones that don't make web
users "queasy" <grin>), then you need to change your paradigm completely
and start thinking of services and sending small bits of data back and
forth. You'll need a solid JavaScript framework to implement the UI -
without it you'll be as lost trying to manually code pages as you would
be if you had to program the 5250 data stream yourself.

I disagree a bit with Nathan about throwing out your existing RPG code.
Depending on how far along the road you are to modularization and things
like called programs and service programs, you should be able to use
that code almost immediately n a good web application.

Anyway, that's probably more than enough for Midrange-Tech; any more
discussion of web architectures belongs best in the WEB400 list.

Joe

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

_________________________________________________________________
Windows werkt zelfs voor je studie
http://www.windows.nl/Theme.aspx?id=2