Re: UI design and build

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