Re: UI design and build

Jon,
Thanks really mucho for sharing the links to your OA articles. I'll be perusing them. Got no place to practice, the company I contract for is preparing the terrain to exit IBM i. But reading them will prepare the brain.

--Alan

On 05/28/2025 7:22 AM EDT Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:


"And we already have that - kinda - with OA-RPG a handler could do that, but a handler is a complex beast, so you would write it one-time and reuse it with every screen."

I wrote up an example of a simple OA handler for the web and wrote up my conclusions in a series of articles on Open Access. You can find them here: https://authory.com/JonParisAndSusanGantner?collection=Open-Access-c6442821ee733408f8374c62e3d0bfdad

In particular the article ""Webulating" Printer Output Revisited" outlined my ideas for a very simple OA web handler. In summary, an OA handler that can deal with any and every 5250 program ever written is VERY hard to do. It would be way, way cheaper to buy one from a vendor. If anyone is interested I can spell out the details of why this is, but we should probably start a new thread on the web list.

BUT ... it is my view that an OA handler could be developed relatively easily providing that there is no intent to use it for anything but new programs. By using the name-association approach I outlined in that article the logic of the handler can be pretty simple.

Any project that wanted to dig deeper could start by looking at the work done by my friend Pascal Polverini who proposed the idea of a DDS replacement under the banner Open Access Definition Standard (OAMOS). Sadly it went nowhere and its website seems to have disappeared. You can read about the idea here https://authory.com/JonParisAndSusanGantner/Life-After-DDS-a954c0b3cb7514babad3740ca7b62c199 one of the Open Access articles in the series mentioned above.


Jon Paris
Jon.Paris@xxxxxxxxxxxxxx

On May 28, 2025, at 5:41 AM, Daniel Gross <daniel@xxxxxxxx> wrote:

Am 28.05.2025 um 02:41 schrieb Infodorado InfoDorado via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>:

Thanks Raul.
One program per screen. Absolutely better, IMHO. Modular programming.

One program per screen - nice idea, but with CGI you often need 2 programs per screen. One that creates is (at least if your screen is not something trivial like a static HTML form) and another program to receive and process the user input - and maybe send something back to the user.

Of course you can do that in one program - but those are completely different and even completely non-related processes, and your program terminates between both processes.

One program per screen with the EXFMT programming model would mean - your program defined the output - EXFMT - and processes the input. Looks like "KISS" to me - especially as it keeps logic together, that should be together.

Am 28.05.2025 um 01:32 schrieb Raul Alberto Jager Weiler <raul.jager@xxxxxxxxx>:

I did suggest to IBM to add new "DEVICE" :web, to use whith an html mask
instead of dds. ( it got rejected)

And we already have that - kinda - with OA-RPG a handler could do that, but a handler is a complex beast, so you would write it one-time and reuse it with every screen.

What I suggest would be:

- using the DDS only for the external format descriptions - do NOT process any DDS keywords, constants, messages or anything

- use a "web-template" - referencing those external formats from the DDS - again only to have field descriptions (data type, length) - everything else is defined new in the web-template

- use a handler to combine both

- use an rendering engine that creates real HTML/CSS/Javascript from your web-templates that looks modern and nice - based on some JS framework out there.

For the web-template I don't think of HTML directly - but more a lightweight description language that defines "screens", "parts of screens" (-> DDS record formats), "fields" (-> DDS fields), "indicators" (-> 01-99, fields or via API), "constants" and "attributes" (like editing, checks, etc).

Some markup language (maybe similar to Markdown, XML or JSON) would be easy to learn - but using HTML directly should be an option, to be future proof.

Last but not least we would need some API to manipulate things in the web-template directly, that DDS doesn't have - like BLOBs or other things. But that would be the cherry on top.

It would merge the "traditional" transaction oriented process model with web-tech - and like Profound.UI could gain some traction - especially if it's open source and free.

Regards,
Daniel

Am 28.05.2025 um 02:41 schrieb Infodorado InfoDorado via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx>:

Thanks Raul.
One program per screen. Absolutely better, IMHO. Modular programming. And for goodness sake, put oft-repeated code routines into a subfile or better yet a subprocedure, or if it's code repeated across multiple programs put it into a service program already.

I can understand the early monolithic type programs, because of the performance considerations.

--Alan

On 05/27/2025 7:32 PM EDT Raul Alberto Jager Weiler <raul.jager@xxxxxxxxx> wrote:
Making one program for each screen makes the development easier
and faster, it also simplifies maintenance.
It is aso important to adhere to the KISS principle.
My issue is they are not price competitive for small

shops and folks like me that would not be building significantly large > > >> applications.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.