The "UI" debate rages on ...
The whole problem with "OA" is, it does not really help to separate the user interface from the rest of the "legacy" application logic and "business rules." The code still has EXFMT (or WRITE / READ) all through the same code that implements database I/O, and "business rules" etc.
How is that "modernization"? Sure, you may be able to put a very nice "mask" over the face of your old applications, but they are still the same old applications underneath, with all the same problems of still being designed as a "monolithic" application.
Far better to spend time to separate the user interface portion into separate procedures, in a separate service program, and ideally, to encapsulate the "business logic" into procedures that perform meanigful business functions such as "book_a_loan" (in a banking application) for example, rather than just having the UI code and business logic all mixed together. Organizing the code in this way, it becomes more "object oriented" even if not coded in a true OO language like C++ or Java, by encapsulating all of the logic pertaining to "loans" into a "LOANS" service program, for example, where the procedures exposed are analogous to "methods" in a true OO language. Also, this layer can maintain in-memory data structures representing the business objects (the "model" in MVC), as well as maintaining a "persistent" copy of the data in database tables, and all of this can be totally transparent to the rest of the application(s).
Ultimately, the main line code becomes just a sequence of procedure calls to these high-level procedures that perform various business related functions.
You could even have a 5250 version of the "user interface" service programs, exporting all the same procedure names as the web versions, and then, by simply manipulating the library list, you can have the same application code base in use by 5250 users and web-based users, at the same time. (I would also argue that a UIM-based user interface would be better for this type of 5250 user interface, because UIM is a tag-based language, conceptually similar to HTML, where the program is isolated from concerns such as the "layout" of the data on the screen, etc., and data are read and written to a "variable pool" of named variables containing values, very similar to what tools like CGIDEV2 provide for substituting data into HTML pages. But that is probably a whole separate debate that can rage on for days, all by itself.)
This approach would also better prepare developers to move into the modern world of using truly modern languages like Python, or Javascript, or C#, or Java, etc., that have true "objects" and "methods" etc., if you should ever need to or choose to do so.
Just saying ...
Mark S. Waterbury
On Tuesday, April 9, 2019, 5:59:51 PM EDT, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
Jon,
It appears that you may be spread a little thin by being engaged in several
conversations all at once on this list, and you're probably busy with work
too. You're way off base in regard to thinking that my perception of what
OA can and cannot do, being slewed by 5250 thinking. I've looked deeply
into OA.
In regard to the purpose of this thread, is it really relevant what is
"possible" with OA?
Moreover, OA web applications implement the display-file write-read
paradigm. The format of the display file may have changed. That's up to the
creativity of the people who designed the OA handler. The Workstation Data
Management function has effectively moved off the IBM i, and has been
replaced by something comparable that is running in the browser in some
cases, or running on an intermediate platform in other cases. Again, how
that works is up to the creativity of the people who design the OA handler.
With OA, the normal client-browser request-response cycle has been swapped
out in order to accommodate the display-file write-read paradigm. That
definitely comes back to bite.
On Tue, Apr 9, 2019 at 2:03 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
" But you give up the ability to respond to any type of event that may
occur at any time within web browsers."
No - you don't have to. Many of the limitations we perceive with 5250s
are imposed by Workstation Data Management. But using OA WDM is not in play
- so neither are the limitations.
I'm not saying that completely designing a new modern UI should be done
with an OA handler approach - although I've seen it done very very well.
But your perception of what it can and cannot do is slewed by 5250 thinking.
midrange.com
