Re: UI design and build

I disagree...

Have you actually used an OA-RPG handler such as Profound UI?

Once a screen is converted, you can enhance it with Javascript to your
heart's content.

Charles


On Thu, May 29, 2025 at 9:08 AM Nathan Andelin <nandelin@xxxxxxxxx> wrote:

In regard to the OA-RPG discussion, with all due respect, there may
have been a business proposition for that, but it was never a good idea
from a user interface design perspective, nor a business application design
perspective, nor should it be considered good technology, because the idea
of writing a "record" to the device, followed by reading a "record" from a
device is too constraining. For example, with browsers you will find times
when you want to embed multiple display panels in a single HTML page, then
use Javascript to toggle their display attribute to show and hide them,
rather than having a program on the server controlling what gets displayed
or hidden. That way, you can avoid unnecessary interaction with the server
while implementing a process-flow in the browser. And if the browser does
need to communicate with a program on the server, it can do so
asynchronously through either "post" or "get" operations, which require
very little bandwidth. Thus you streamline the interaction with the server
and make the user interface more responsive. Under the OA-RPG paradigm, you
never really improve the user interface, you just add overhead to it!


On Wed, May 28, 2025 at 11:37 PM Daniel Gross <daniel@xxxxxxxx> wrote:

Hi Jon,

Am 28.05.2025 um 23:36 schrieb Jon Paris <jon.paris@xxxxxxxxxxxxxx>:

If you haven't already done so I strongly advise you to download and

use

my OA template program. All the fundamental logic including state
preservation is there. Don't waste time re-inventing the wheel - improve
the design of the tires or add magnesium trims or ...

Thanks - that's a good idea.

Re feedback areas. Forget them. <snip>

OK - I thought just to fill some info, but I have seen, that's not
necessary.

The first para is the right idea. But realize that even then if you do

not restrict DDS usage you still have issues. Just to name a few.

1) You basically can't easily use indicators because the handler won't

know about them.

I have seen the indicators in the namesValues array as '*INxx' - at least
those used in the format that I sent.

2) Overlapping fields. Nope - the handler will see both and have no

idea

which to use

That's OK - send both - let the "template" decide which one to show -

just

like DDS.

3) Edit codes. Nope - you won't see them so you have to find some way

to handle that

Output format (edit) and input format have to be define new.

I think about to only use the record format as a "transport medium" for
the data from RPG to the template and back to RPG again.

4) Without using naming conventions you can't tell a subfile record

from

a subd=file control, from a ....

That's also OK - one would have to define the usage of the record format
inside the template new.

Like you define a fixed format with data and the table header and footer

-

and then embed any other record format (whether it was defined as a

subfile

or not) as table rows.

As I said - ignore everything from DDS - only use the raw record formats.

And in the template just use the record format and field names - plain
simple. If one writes a record format multiple times, then the part

marked

for that record format is just repeated multiple times.

So you can even combine multiple formats as you like - just like OVERLAY

-

but much more flexible.

This is just a tiny fraction of the potential problems. Hopefully this

makes it a little clearer as to why I said you need to design for NEW
programs with no thought of simply adding a Handler keyword and

repurposing

existing ones.

100% - maybe you can use some programs as the are - but that's not the
central idea - there are enough good products out there, that do that -
like IceCap.

By limiting it in tnis way I think you have an achievable project which

onve proven could grow.

That's my hope.

You're welcome. Keep it simple, KISS really is the way to go with

this. Evolution not revolution.

Yes - keeping it simple is the only option for a small group of open
source developers to achieve anything in a timeframe that doesn't deem

the

idea irrelevant again.


Thanks again - I'm really looking forward for more feedback. I already
looked at ILEastic - a possible solution for the web server

infrastructure

- and apug - a IBM i implementation of the pugjs template engine.

It seems, that nearly everything that's needed is already out there -

more

or less.

Right now I think the most complex part would be the "web server" that

has

to somehow hold the programs in memory during the EXFMT (maybe 1 job per
session with ILEastic and dynamic ports?).

As I said - I have to sort all those ideas a bit - then I will post a
"RFC" maybe on GitHub so everyone can comment and bring ideas to it.

Kind regards,
Daniel
--
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.