Re: UI design and build

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.