Nathan,
replies are in-line.
On 6/9/2015 5:20 PM, Nathan Andelin wrote:
Monolithic applications tend to generate a lot of
technical debt over time that makes them less "sell-able", much harder to
maintain, and ripe for replacement.
You have heard my name before, haven't you? If not, then please know
that I've spent the last 12 years writing articles, speaking, and
teaching people to move away from monolithic architectures. You are
preaching to the choir!
You seem to assume that if it uses a display file, it must be
monolithic. Take a step back and think about that... there's nothing
stopping you from putting display files in subprocedures, splitting
display logic into it's own module, etc.
Regarding the <iframe> issue, could you clarify whether <iframes> are a
component on the Profound UI screen designer? If not, then why not? I can
see developers embedding <iframe>s in pages, including one or more frames
hosting separate Profound UI "sessions".
iframes are a component in our Profound UI Visual Designer. You can
drag/drop them to place them on the page, size them, etc. When the page
is rendered, the iframe component will fetch the URL it points to and
put it in the frame, just as it would if you coded the <iframe> tag by
hand. You can embed JavaScript in the page that changes the iframe on
the fly, and of course, JavaScript in the parent can communicate with
JavaScript in the iframe, just as with HTML. We're just generating
DHTML from our framework and letting the browser do the work, so it
works exactly like any other iframe.
But I don't see how a display file and op code paradigm could handle
requests from events which may be occurring in multiple <iframe>s
simultaneously. I could see having frames handled by separate
"applications" and "sessions". Was that what you meant by having
customers doing that all of the time?
From a display file perspective, the RPG program does an EXFMT (or
WRITE or whatever) opcode to show the format, and the format contains an
iframe. When that format is rendered, the iframe executes another URL
and puts it in the box. If that URL references another OA application,
then a second HTTP server job is started to run that additional OA
program, causing that RPG program to get run and for it to do another
EXFMT or whatever so that it's output will appear in the iframe.
Of course, if that URL points to a non-OA application, then it works
like any other web page in an iframe... no magic here.
I reviewed what I wrote previously. I probably confused people by talking
about <iframe>s and SPA "containers" in the same paragraph. They are very
different architectures and interfaces. Maybe I'll say more about SPA
containers later.
Didn't confuse me. Our Rich Display applications are all SPAs, these
work extremely well for business application UIs. But less so for
public facing web sites -- we have alternate ways of doing those, though
you can still use OA for that if you want... we have a "Universal" OA
handler for stateless, traditional, web applications in addition to the
"Rich Display" approach.
But, iframes work fine in either case, and customers do this sort of
thing quite often.
midrange.com
