× 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.



The point you are missing I think Nathan is that OA based products such as Profound _can_ be used to build the kind of apps you describe.

But I still recommend most of my clients to start with enhancing what they have because that will provide a learning framework. All too often refactoring and other major enhancement projects fail because the staff are not familiar with the capabilities of the web interface - in other words they don’t know what questions to ask. By starting off with what they know and stretching its capabilities (which is what OA enablement is really all about) they get to learn what they could be doing.

As an example - I have one client who purchased Profound with the intention of webifying some of their 5250 apps. In going through that process they discovered the capabilities of the tool and ended up building a new app (much along the lines you describe) not to replace a 5250 app but to replace a .Net app! But had they not had that 5250 potential in front of them I’m pretty certain that they would still be doing the “deer in the headlights” routine so prevalent among IBM i shops.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Jun 9, 2015, at 10:57 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:


Something like Profound UI's tooling seems ideal - no change needed to the
RPG code at all


Nice endorsement, Vern. I agree that Profound has good tools for IBM i
application development and good people supporting them. But I think it is
important to note that there are trade-offs associated with every tool-set
and "modernization" methodology.

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.

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".

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.

With browser caching as an option, it is possible for developers to decide
whether to refresh a screen by making a server "request", or to just use
what's available in cache.

If green-screens are not sell-able, what makes HTML renderings of the same
applications more so?

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 the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.