Actually, my response was to Aaron and only because the ephemeral "solid
business application" is thrown around so often that it is taking on the
characteristics of Bigfoot or Elvis sightings, everybody says there is one
and all I am seeing is "fuzzy photographs". Knowing what would comprise a
"solid business application" was what I was after from Aaron.
The reason I pick something like order entry as a "solid business
application" is because it will most likely cross over all the areas of
technology that will need to be tested out to find the successes and
failures of any given framework/language.
The following are a few points we can start with for what I consider
requirements for a "solid business application".
1) Going back to one of my earlier posts today I mentioned the fact that
many of these drag and drop tools don't implement paging of a large data set
efficiently (i.e. they copy the entire dataset into a Collection and page
through that Collection in memory vs. going back to the database and
resequencing or getting the next set of records). Could somebody show us
whether or not EGL gives us efficient paging out of the box? BTW, the same
would need to be implemented in RPG-CGI, and obviously RPG-CGI doesn't have
it out of the box either.
2) Does he framework allow for the same screen sequence to be entered into
from different initiating screens? Let's say you have an "Advanced Customer
Search" set of screens that you wanted to access from both order entry,
customer maintenance, and customer service. In traditional RPG it was as
easy as calling the "Advanced Customer Search" screen with a set of parms
and hitting F3 when you wanted to back out to the previous screen. In JSF's
out of the box approach (and I don't know if EGL suffers the same fate) you
essentially hard code the next screen to be displayed based on your
faces-config.xml file which essentially means you can't just hit F3 and go
back up the call stack because there isn't one. Instead I had to spin my
own wool again to make this work (and even then I don't feel I was entirely
successful).
3) Does the framework allow for the easy mapping of screen fields back into
the controller? RPG *DSPF has this, EGL/JSF has this, RPG-CGI doesn't have
this without some work.
4) Does the framework allow for easy stateful programming. JSF did pretty
good with this when you defined your beans as "session", I am assuming EGL
has the same efficiency, baseline RPG-CGI is lacking, though it wouldn't be
too hard to fix which is something I am working on (think matching incoming
requests with a unique session ID to a program waiting on a keyed data queue
for that specific session id entry).
5) Does the framework allow for seamless client to server event
notification? JSF does good in this arena by allowing you to say things
like onClick="Javaclass.javaMethod". This is one of my favorite features of
JSF because it is so stinkin easy to process a user interaction separate
from other potential user interactions on the same page. RPG 5250 had this
based on the key pressed logic we are all familiar with. RPG-CGI doesn't
necessarily have this, though it could be built by using system API's to
dynamically call a service programs sub procedure with event information.
6) This one might seem picky, but it saves me time when I use it in JSF:
Does the framework allow for seamless determination of which link in a row
of links was clicked. JSF does this great. RPG 5250 had it even better.
RPG-CGI is somewhat lacking because it is spin your own wool.
So there is the start of an initial short list of things I would consider
necessary in a framework. If others have things they would like to add to
this list, or modify my initial statements to be "more correct" then maybe
we could start a wiki page on midrange.com that discusses things to look for
in a framework to rule it in or out as an option for non-trivial business
system development. Thoughts?
Aaron Bartell
http://mowyourlawn.com
midrange.com
