Hello,
Let me please respond in-line:
On 6/9/2015 9:57 AM, Nathan Andelin wrote:
Rather than "no change needed to the RPG code at all", a higher priority
might actually be to refactor some code, eliminate some, and replace some
to fit within an application architecture which is more maintainable over
the long run.
I agree 100%. There are three important pieces to modernization:
1) Modernize database to fit today's database requirements
2) Modernize code to simplify maintenance
3) Modernize displays to keep applications looking/feeling modern to users
Profound specializes in the 3rd piece, but we do not tell customers to
ignore the other two! Our tools work very well both with unchanged
RPG/database and with new/modern RPG and database.
It's very similar to IBM's philosophy for the OS, which has always been
not to *force* customers to rewrite their applications when doing
upgrades. We are the same, we recommend that you modernize your code
and database, but we don't force you to do so. And I agree that people
should refactor and improve their architecture, et al.
Another priority might be to provide a UI which automatically adapts to all
classes of devices (cell phones, tablets, laptops, desktops) rather than
separate "display files" and different applications for different sized
screens. This strategy is known as "responsive UI design".
Profound does provide that capability, we have a whole section of tools
devoted to this because (especially with mobile) it's very important to
adapt to different classes/sizes of device. This same technique is also
very important for when a user rotates their screen on a mobile device.
I like to use <iframe> elements, but having multiple frames in applications
doesn't fit with an Open Access architecture. I advocate for "single page
applications", where each "page" may be divided into many "containers",
where each container has a different layout and different data; where the
content is dynamically "injected" into each container as needed over the
lifespan of the application.
I don't see why that doesn't fit the OA architecture? We have customers
doing that all the time...
If green-screens are not sell-able, what makes HTML renderings of the same
applications more so?
This is something I strongly agree with. We sell tools such as Genie
(screen-scraper) that essentially render the 5250 screen in a browser
just as you'd see it in a 5250 emulator, and this is not a long-term
solution to the problem. It's a temporary solution to get to the web
while you work on building better displays to replace them with.
It is a very useful "bridge", because doing a "big-bang" where you try
to update 12000 screens and put them all live at one time is simply not
practical. Too much upheaval, too high of a risk.
Instead, what you do is use a screen-scraper type tool to get everything
running in the browser at a lower risk. Then, you can use our Rich
Display tools (Our OA product) to build modern displays for the future,
you can use things like iframes and sections that are AJAX-driven divs,
and stuff like that if you want, and create the modern displays you need
going forward, replacing one screen at a time.
Our tools are smart enough that when you use the OA handler to output a
rich display, it'll show the rich display, but if you output a 5250
screen, it'll go into screen-scraper mode. So this allows you to
replace one display at a time, get user feedback, concentrate on the
displays that need it the most, etc... but still have all applications
available to the user in a single seamless interface. (They don't have
to switch between green-screen and web, because all the green screens
work in the web.)
In the long term, of course, the goal is to redo everything and
eliminate the 5250 part completely.
I agree that leveraging existing code-bases and skill-sets has value;
hosting applications on IBM i has value. But to fully utilize browser
capabilities, people need to learn to code differently.
This is definitely true, and our products assist them in doing that...
midrange.com
