× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Gz, Nathan, are you TRYING to get me to flame on?  <laughing>

While many of your points are valid, you skew them to the point that you
are no longer providing good information.  Let's take a few.

"The problem with function keys..."

Function keys work outstandingly well in IE, and not so well in non-IE
browsers.  Thus, the situation is simple: if you have control over your
browser and standardize on IE, you can use function keys.  And while
some folks may get upset if you don't support their pet browser, the
truth is that well over 95% of business desktops are Windows, and thus
have IE.  Because of this, you can reasonably standardize on function
keys for inhouse apps.

For pure C2B web apps such as storefronts, you can use the W2C standards
for keyboard accelerators (thing like Alt and Ctrl).  They work quite
nicely, and can be quickly and easily substituted for function keys.
With a simple JavaScript switch, you can flip between function keys and
accelerator keys.


"If you decide to front-end existing green-screen applications with an
HTML interface,..."

I don't know where you get your figures, Nathan, but a typical well
written HTML page is about 5K, a large one may get up to 10-15K.  Larger
than a 5250 datastream, to be sure, but that's hardly an issue.  I can
play with numbers too: on a gigabit Ethernet line it takes LESS THAN A
MILLISECOND to send that data.  As to the tremendous amounts of CPU
overhead ("some Java interfaces consume 30-50 times"), in fairness you
ought to post the numbers for a good Java interface to an RPG back end,
where the actual CPU cycles consumed for the UI is a small fraction of
the overall numbers.  This "any savings in ... may be gobbled up" is
pure FUD.  I suggest you prove these numbers with a real world
application.  Then give me a week to tear the thing apart and make it
run correctly and all your FUD numbers will magically disappear.

This is not to say there is no overhead associated with Java.  What I'm
saying is that a sufficiently thin JSP interface compares favorably to
any UI out there, and can even run comparably with a green screen 5250
interface.


"Scripting languages like JSP..."

JSP, especially JSP Model II, is anything but a scripting language.
Especially since the JSP is first converted to Java code and compiled
into bytecode, which is in itself faster than a scripted language.  But
then the bytecode is itself compiled into machine code by the JIT
compiler, at which point the Java code is running at speeds equivalent
to compiled RPG.  In fact, for certain operations compiled Java is just
as fast as compiled RPG.

So please don't lump JSP in with the other architectural approaches.
None of them are capable of taking advantage of the flexibility of the
JSP design.  There are some things that Java doesn't do well, but UI
isn't one of them.  JSP Model II may well be the most efficient user
interface standard out there, especially when you factor in ease of use,
a broad knowledge base and platform independence.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.