Could you briefly summarize what the problem is? You can keep state
between calls in the session object so it must be something else.
One of them that I thought of after reading your email (and after working
outside a bit) was the fact I had to spin my own wool to get a "robust"
paging (read subfile) mechanism in place. By default the tools like JSF
think you can just load a couple thousand records into a Collection object
and not have it affect performance once you have 30 to 50 users all hitting
the same app at once. They build the UI components expecting to have
control over the whole SQL result set in it's entirety vs. a subset based on
a LIMIT clause (or something of that nature).
In the end some of it comes down to "knowing what you are doing" when you
first get into building applications with a new framework. I
whole-heartedly admit I didn't understand all of the ramifications of
adopting JSF "out of the box" and show have instead stopped drinking the
KoolAid and took a pragmatic approach vs. get too excited over the features
I saw that solved 30% of my "get work done fast" problems.
More that you are guaranteed there is a light at the end of the tunnel
regarding the strategic platform you need to write your stuff at. Why
save time using some kit, if you just postpone the pain to later when it
will kill the patient?
We are reaching a point in the IT dept infrastructure where "framework
evaluator/builder" is actually going to be a job description. I predict
that in the next 5 to 8 years we are going to find that people will see the
mess they created by adopting 5 different languages for different apps based
on a variety of personnel hires, vs. sticking it out with whatever language
they are most competent in (whether that be RPG, .NET, Java, EGL etc).
IMO, Service Oriented Architecture internal to a company with multiple home
grown systems using a variety of languages and platforms is only a band-aid
delaying fixing a companies infrastructure. The fixing is being done
because poor decision making was made by people uneducated in picking a
software stack - I have played the "uneducated" role, so I feel like I am
speaking from experience:-)
Oh, by the way, what would you recommend using for writing non-trivial
applications of the kind we are discussing here?
A custom and home grown software stack. I am assuming we are talking about
writing non-trivial apps on the iSeries so I will slant my recommendation
towards that, though my recommendation would change if the iSeries wasn't
already present in the IT shop. Since we are on the iSeries I would
recommend using RPG as the DB access and business logic layer. The more I
work with it and the more I compare it to other languages like Java/PHP/C#
the more I like its "limited" modularity. By limited modularity I am mostly
capitalizing on the fact that I haven't seen an easy to maintain OO related
object structure in languages like Java/C#/PHP and find that as long as I
can have an encapsulated group of uniquely named procedures (i.e. sub
procedures within a service program) that is really all I need. Obviously
the same can be accomplished in Java/C#/PHP, but again we are on the iSeries
so I would use RPG.
This next recommendation is where I am going to draw a line that some
haven't agreed with me in the past, but I think it is fundamentally
important to large scale non-trivial applications. If you are having your
business logic and DB I/O in RPG then you should also have your controller
logic in RPG!!!! For awhile I took for granted how nice working in one
language was and thought nothing of putting a different language on the
front-UI-building-end vs. the back-business-logic-DB-end. After awhile the
in-efficiencies of heavy usage adopting of two or more high level languages
in a single black-box application stack will begin to rear their ugly
heads. I am NOT saying such a framework wouldn't be successful, but I am
saying it will be less productive than having a single language act as all
three previously discussed layers. Why? Because more than likely you will
have two different personal required to fix any given problem. Usually the
way duties get separated out with this latest modernization sweep is by
technological competence vs. business competence (think of how a single RPG
programmer could develop an entire inventory system all by themselves
without requiring somebody else to build their DDS for them). Those days
are seemingly gone because of the complication introduced into the software
stack, but the crazy thing is that we continue to welcome it vs. demand
better from IBM in the RPG centric space.
So now that we have established my preference to build a system whose
controller, business logic and DB I/O code is all written in RPG, we have
one last point - what does the end user interface look like and how is it
built?
Obviously the last step of creating a user interface has to include the
browser because that is how external people will prefer to access your
company. Obviously RPG doesn't run on the desktop or literally in the
browser (i.e. you can't literally send a *DSPF to the browser and have it be
rendered), so at this point a new non-iSeries native technology needs to be
introduced out of necessity. This is where I would employ writing the
"custom framework" portion to meet my business need, because I have already
ruled RPG to be solid in all other aspects of programming. The custom
framework will allow me to send meta-data (e.g. an XML form similar to an
HTML form) to/from a user interface device from the RPG language. The
custom framework talks to RPG through a medium that allows for the stateful
persistence of an RPG program (I am leaning towards data queues) while
talking to the UI layer which is most likely running on the client. The
custom framework can be written in any language that works on the client's
machine (i.e. in the case of the browser it would be Javascript/HTML/CSS, in
the case of the desktop it could be Java or .NET, in the case of a
Blackberry it could be Java or WML), as long as that framework can talk to
the data queue on the iSeries to send and receive the meta-data.
I have built such a custom framework in Java that ran on the desktop and
J2ME devices (Canon copiers specifically) that "talked" via XML forms to a
backend Apache server running Perl as its controller, business logic and DB
I/O language. The most important thing about the framework is that we
needed the client piece to completely draw screens based on meta-data
because we could only install one version of the software ever (I wont
digress into that subject). What that meant was I had to develop the Java
code in such a way that everything could be changed on the fly by the server
language (Perl) without modifying my application. This meant that if the
Perl guy wanted to add a new field or switch the display order of screens 5
and 7 in a sequence, it could all be done from the server side without ever
having to redeploy Java code to the client. I also had to make sure the
Java code was efficient enough to run on a J2ME device with a fairly small
amount of processing power. In the end you could say I wrote my own
browser, but I did it in a fashion that wasn't restricted by an HTML spec
developed 10 years ago. For instance, you could stack screens on top of one
another similar to how you go into an RPG application and can go many levels
deep and then hit F3 to back out of each level.
I have been working at modifying it to the point of getting it to the
community to evaluate it to see what we can do with it - needless to say it
still isn't out yet:-)
The important thing to note about the last step of building the custom
framework is understanding how to pass data in different ways and how to
appropriately process user interactions. For example, you need mechanisms
to support the sending of simple single field data sets along with sending
complex multi row data sets. On the flip side you need to be able to
receive the same thing - complex and simple data sets. You also need to
have infrastructure to process user events from the client to the server and
appropriately map those events to a "handler" on the iSeries (most likely an
RPG sub procedure). I guess in the end you really need to understand the
patterns of data flow into and out of your application and then you can
start building custom framework prototypes.
Sorry for the long and probably loose-ended response. I hope to put
together an article series on just this topic full of actual code examples
showing implementations (I have one set partially developed for iSeries
Network that I just need to round off) and describe the shortcomings of the
different approaches.
Aaron Bartell
http://mowyourlawn.com
On Sat, May 24, 2008 at 6:31 PM, Thorbjørn Ravn Andersen <
thunderaxiom@xxxxxxxxx> wrote:
Aaron Bartell skrev den 24-05-2008 21:33:
The thing that caught my eye with JSF four years ago is the fact that it
delivered mapping of screen variables (i.e. HTML <input /> fields) right
into getters and setters in my .java controller/POJO (I had to do no
plumbing for that). The other thing I REALLY liked (that I hope to
duplicate in RPG) is the ability to map a user interaction to a specific
method in a class. It just made it so easy to create a page without
having
to do much plumbing. These are the things that STILL save me time.
I also really liked the way that you can refer through maps and beans
with a concise syntax instead of dealing with tons and tons of getters
after one another.
There are some rather nice things which is much better than both plain
JSP as well as struts. I am looking forward to brushing up on this
again, as the JSF-app I wrote most likely is due for revision.
One thing I really, really liked was an extension to MyFaces which
allowed me to access both the variable context of the page I was coming
from (inside loops and all) as well as the page I was going to. This
allowed me to essentially provide the relevant info in the link instead
of having to build transfer beans for each and every link type. That
was very nice.
Unfortunately I cannot use JDBCto talk to the legacy system otherwise my
life would have been much easier with rowsets and all.
The issue came when I had to go outside of the JSF spec author's ideas of
web page processing. This is where Joe and I had our disagreements
earlier
this year (and around Thanksgiving last year). You can search the
archives
for them if you wish to know the points I ran into (which inherrently
*might* have the same issues in EGL being JSF is EGL's plumbing).
Could you briefly summarize what the problem is? You can keep state
between calls in the session object so it must be something else.
It would be interesting if IBM ever made the EGL spec open source and
added
their value through tooling. That would give it much more acceptance
much
faster. As it stands there are less EGL
developers/books/documentation/etc
out there than RPG right now, and if it doesn't take off like IBM hopes,
then there is *a* chance IBM could pull the rug out. Yes this sounds
like
You know my opinion on the matter :) I have just one more - the more
liberal license with jt400 as opposed to client access allows us to ship
binaries to clients embedding jt400. We cannot do that (AFAIK) with
client access due to its license, and installation procedure.
FUD, but it is FUD with history to prove its potential. I think
Thorbjorn
(spelling) said it best with the statement (paraphrasing) "it is safer
for
me to go with open source because then I can choose how I put my
framework
together and not have to worry about IBM/Microsoft/etc changing
directions -
I 'own' the framework".
More that you are guaranteed there is a light at the end of the tunnel
regarding the strategic platform you need to write your stuff at. Why
save time using some kit, if you just postpone the pain to later when it
will kill the patient?
If IBM really, really, really wantet EGL to hit big time I also think
they should throw it in the Eclipse bin and make it usable everywhere,
but work the best on IBM's own machinery (simply because that is what is
supported). These days we have a choice and to make a new choice that
locks you into a platform and vendor choice is as bad on the i as on
Windows.
I have seen enough "interesting cases" of Java on the i to say that it
is not a troublesome path, but I am also certain that well-written Java
code may live for ever as the platform will not go away. This is due to
the specs and the GPL on the source - THAT is what will fullfill the
original "write once, run everywhere" (instead of everywhere being
Windows and Solaris (and Linux but it wasn't originally) plus OS X after
a year or two) as all the various alternate operating systems will have
a JVM.
Also, when a mechanism is created that allows Java stuff to start
"immediately" we have a new situation for writing normal command line
utilities (Flash has conquered the applets).
Until then, well EGL is most likely a great prototyping tool, but would
you bet your company on it?
Oh, by the way, what would you recommend using for writing non-trivial
applications of the kind we are discussing here?
--
Thorbjørn
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
midrange.com
