× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.