John,
As I'm now retired and therefore have almost unlimited time, this idea sounds interesting to me. Where do you suggest I start my investigation? I guess that if I google Google Wave it will lead me to additional information. I'll do that immediately.
Ralph McDonald
----- Original Message -----
From: john e<mailto:jacobus1968@xxxxxxxxxxx>
To: web400@xxxxxxxxxxxx<mailto:web400@xxxxxxxxxxxx>
Sent: Wednesday, October 07, 2009 1:31 AM
Subject: Re: [WEB400] Modernizing Green Screen Was: Re: IBM HATS vs. ?
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<mailto:jrperkinsjr@xxxxxxxxx>
> To: web400@xxxxxxxxxxxx<mailto: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<
http://twitter.com/the_jamezp>
>
>
> On Tue, Oct 6, 2009 at 15:05, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx<mailto: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<mailto:WEB400@xxxxxxxxxxxx>
> To subscribe, unsubscribe, or change list options,
> visit:
http://lists.midrange.com/mailman/listinfo/web400<
http://lists.midrange.com/mailman/listinfo/web400>
> or email: WEB400-request@xxxxxxxxxxxx<mailto:WEB400-request@xxxxxxxxxxxx>
> Before posting, please take a moment to review the archives
> at
http://archive.midrange.com/web400<
http://archive.midrange.com/web400>.
>
_________________________________________________________________
Windows werkt zelfs voor je studie
http://www.windows.nl/Theme.aspx?id=2<
http://www.windows.nl/Theme.aspx?id=2>
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx<mailto:WEB400@xxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400<
http://lists.midrange.com/mailman/listinfo/web400>
or email: WEB400-request@xxxxxxxxxxxx<mailto:WEB400-request@xxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/web400<
http://archive.midrange.com/web400>.
midrange.com
