On Tue, Apr 9, 2019 at 6:51 PM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:
The "UI" debate rages on ...
Your post included a lot of thoughtful input, Mark.
Some 5250 developers express concerns about learning HTML, CSS, and
JavaScript. I'd like to alleviate those concerns and suggest that they'll
enjoy it very much because it provides a surge to be able to improve the
user experience and functionality of your applications. After learning a
little, you begin to see how you were shackled by the 5250 and display-file
paradigms.
Under the display-file paradigm, a typical thing is to assign "attributes"
to input and output elements on a screen, condition those attributes with
indicators, then write server-based codes to set the indicators on and off,
according to the effect that you want to implement.
Under a browser client-server paradigm. UI elements have a broad range of
inherent attributes that may be dynamically modified during run-time via
JavaScript by referencing the element's ID or name. For example:
element.enabled = false;
Might be coded to disable an element's input capability, and cause the
element to become shaded.
Under the 5250 paradigm you must engage the server in order to achieve a
similar effect, which in my opinion is a waste of I/O and other server
resources. Use a little bit of JavaScript and you end up with a lot more
efficient and intelligent use of local resources.
One complaint with OA handlers is that the size of the data streams that
are exchanged between client and server increase so much, along with server
processing. An interface that once appeared snappy due to minimalist 5250
data streams, lag after implementing an OA handler. OA data streams
effectively perform full page at a time updates.
It makes a lot more sense to use local resources for UI effects,
asynchronously request minimal server resources when the DB is required,
and perform minimal UI updates via the response.
midrange.com
