Nathan and Scott
I think you are using the same acronym like SPA and “responsive design” in
different interpretations.
I agree with Scott that “applets” is outdated since they refer to binary
plugins in the browser (typically written in Java).
Another thing is that we are discussing quite different application types.
SPA and “responsive design” may be hot when creating let’s say a dynamic
homepage in WordPress or small isolated applications but may not be very
hot when you create a Business Application driven by a Viewport with a lot
of information displayed in subfile like rows in a number of active tabs
(<IFRAME> etc.).
The reason for this is obvious since “responsive design” means that you
automatically do a vertical scale of data in horizontal rows or
“containers” to avoid horizontal scrolling.
Imagine this grid and its rows vertically scaled, it would become
unreadable:
http://5.103.128.110:6380/pextcgi/PXWKPXXR.pgm?ses=16797563520630953620151037311052&req=12990983680615004820151040311068&pxTS=20150503103836746
IMO SPA isn’t basically consistent with <IFRAME> since SPA means that you
load and run the application in one scope of the DOM while <IFRAME>’s are
independent browsers with their own code base that runs in their own scope
within the primary scope (the initial page) of the application.
This doesn’t mean that SPA and <IFRAME>’s can’t be mixed it just the other
way around. In fact we have done it for years since a 5250 Work With
function with one DSPF with several displays actually works like a “mini”
SPA controlled by the 5250 program’s controller and the <IFRAME> is the
5250 program and the Viewport is the main job/menu system where we may hold
a number of different 5250 programs active and in state using group jobs.
This has however nothing to do with a monolithic approach. Like a 5250
program a “mini” SPA running in a <IFRAME> can be made monolithic (bound to
a single and specific server program) or non-monolithic using a SOA
oriented architecture where the SPA is launched by one server side program
(or even a static IFS file) and then uses generic REST/CRUD services to
send and receive data to/from the server’s DB.
The coding techniques are of course different but the main architecture and
the result is the same.
Why use <IFRAME>’s? To me they are essential if one must do a system
modernization. Let’s say we have a customer that wants his 5250 programs
lifted over in a browser based UI. The customer has 5250 products from 10
different ISV’s and you have to create a Web interface in a short time
moving all screens in a block including all 10 ISV’s 5250 products. At the
same time the customer wishes to modernize his own 5250 environment in an
ongoing step by step process.
The only way you are able to achieve that are by initially screen scraping
the entire 5250 environment. But that is not really what you want to do. So
you have to create an environment where you run a mix of “new” stateless
programs and screen scraped stateful programs.
<IFRAME>’s are essential to such a strategy since you can run “mini” SPA’s
in each <IFRAME> controlled by the Viewport and where each SPA in its
<IFRAME> either runs programs in the stateless or stateful environment.
Another thing about <IFRAME>’s is that you aren’t limited to only one
stateless or UI technique. Things changes fast in web development and
“modernization” is an ongoing process that often requires much UI rewrite
since backward compability is hardly known in web development. Just take
going from XHTML>HTML5, CSS>CSS3>SCSS, EXTJS3>EXTJS5, Angular 1.x>Angular
2.x or Javascript>Typescript not to mention what will happen when ECMA
script 6 becomes available. You simply need “containers” that can embrace
the new code and techniques without disturbing the “old” code and without
the need to unit test the entire system.
In a cloud environment this becomes even more necessary since you may have
to plug in other vendors cloud or GUI applications into the main viewport
so the system from a user point seems as one system with one login.
So to me the whole discussion about using SPA, responsive design and
<IFRAME>’s is very much depended on the type of application you want to
write. Small standalone applications and CMS tends to point at
SPA/responsive design, large Viewport based mixed desktop applications with
maybe thousands of different “pages” and functions (with a lot of
information in each page) points at using <IFRAME>’s, but there is no “One
size fits all”.
I do however also notice (based on Scott’s description) that Profound do
the opposite of me, since they apparently uses the stateful RPGOA
environment as the primary environment while I uses the stateless
environment as the primary environment with the purpose of phase out ILE
based stateful programming thus minimizing server code dependencies.
On Wed, Jun 10, 2015 at 4:24 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
You have heard my name before, haven't you?
Scott,
Thanks for the reply. Of course I know who you are. Seems odd that you'd
ask. I wasn't preaching to the choir. My posts are for everyone. Sorry if
it seemed like me singling you out. I was suggesting that shops which are
gaining greater awareness of the technical debt in their legacy systems are
more likely to look at web application architectures other than "display
files" and OA interfaces.
Regarding "applets", consider definitions from www.dictionary.com:
"a small application program that can be called up for use while working in
another application."
"a computer program that runs within a page on the Internet."
"A small computer program that has limited features, requires limited
memory resources, and is designed to be downloaded from the Internet to run
on a webpage."
I think "Applet" is a better term than "JavaScript Framework" because the
latter implies a library of functions for JavaScript programmers; like
JQuery.
Your point about it being written in JavaScript rather than Java is well
taken. I'll try to remember to make that distinction in the future.
The main point is that it is an application which performs a service which
is comparable to a 5250 emulator; runs in a web page, transforms meta data
streams received from an OA handler into visual elements, forwards data
changes and events to the server which occur in the client. The
similarities to 5250 are remarkable. Its noteworthy that Profound "owns"
the interface rather than IBM, and can adapt it.
Thanks for the information about <iframe> support in the Profound UI Visual
Designer. I just note that each <iframe> references a separate Profound UI
"JOB", or other external resource, and not belabor the point.
Regarding "Responsive UI Design", I would suggest viewing the link I posted
earlier, using a cell phone, tablet, and desktop screen. The layout
automatically adapts to the size of the screen. Looks better on a cell
phone than on a big screen monitor in my opinion.
http://www.radile.com:9220/rdweb/phones/phonelist.html
You don't need to be a skilled UI designer for that. The "list" is
generated from this HTML template:
http://www.radile.com:9220/rdweb/phones/phones.html
The "detail" is generated from this:
http://www.radile.com:9220/rdweb/phones/phone.html
I could do more to improve the appearance. But that was not my focus. I
carelessly threw the HTML together based on the layout of some JSON objects
which I downloaded from the Angular JS web site.
The point is that one may prefer using that approach, rather than designing
separate "display files" for different screen sizes.
--
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.
midrange.com
