Re: Vendor presentations

["Bryan Yates" <byates@xxxxxxxxxxxxxxx>]

Nathan,

You may have already done this, but before you make a final decision, I
would recommend that you download and try some of these solutions. Most
have at least a trial period product that you can download and use. If
you want to try java, use the WDSCi client and try out the development
environment.

We use JSP & servlets on a portion of our website, but our more robust
applications are coded using RPG and the RPGsp tool. I have tried the
cgidev model and quite frankly, I hated it. In my opinion, it is slower
in development and harder to debug. The RPGsp tool lets me view my code
in WYWSIG, html&rpg code together, or with the rpg code isolated. I can
debug from inside the IDE. Using the wizards, I can create a simple
application in a minute or two. A more complex application (like this
one http://www.collincountytx.gov/rsp-bin/pbkr125.pgm) which pulls
together wide combinations of data can be done in a few hours.
 
In respect to application maintenance, RPGsp is the hands down winner,
despite the recompile. Pop it open, make your change, press the compile
button, your done. I can change from development, to test, to production
environments with a couple clicks of the mouse. Product support is
excellent.

We have written about 18 complete applications comprising around 700
programs using the tool for both our internet and intranet sites and
could not be happier with another product.

As for speed, I'm more concerned about development time than response
time in general, but we replaced our Java servlet case lookup with the
RPGsp version because the CGI application is faster. I cannot speak to
Joe's model of a jsp page to a rpg backend, because we never tried it.
The idea seems good, but I wonder if I would not have the same hate for
it that I do for the template model.

That's my opinion on things, but I'm just a dumb ol' country boy who has
never written a book or published an article in an industry rag. I just
hoe my row.

Bryan Yates
SR Systems Analyst/Programmer
Information Technology
Collin County Government
http://www.collincountytexas.gov
mailto:byates@xxxxxxxxxxxxxxxxxxxxx
 
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Nathan Andelin
Sent: Wednesday, May 24, 2006 11:33 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Vendor presentations

[Why is it that every time I post something wanting people's opinions, I

spark a debate?...Can't we all just get along?... ;^)]

Well, there are a number of competing languages, products, and
architectures.

During the CGI vs. JSP discussion, Seth Newton of Profound Logic pointed
out the efficiency of  embedding HTML and RPG in the same source file,
and using a tool to generate code that simply writes a stream vs. using
a template approach like CGIDEV2, which separates HTML from RPG code but
requires calls to procedures like updHTMLVar() which adds quite a bit of
overhead.

Brad Stone, on the other hand, pointed out the advantage of keeping HTML
separate from RPG from a maintenance perspective.

I found myself contemplating whether there was a way to keep HTML
separate from RPG but avoid the overhead of replacing field markers in
templates.  No, I couldn't come up with a good way of doing that, so I
found myself left with the choice of going with an architecture that has
a cleaner programming interface but adds quite a bit of overhead, vs one
where the code is more difficult to understand and maintain, and locks
me in to a code generator, but is more efficient.  I finally decided
that cleaner code was more important.  This was a difficult decision for
me because I've always given performance quite a bit of weight.

It's possible with a combination of Servlet, JSP, and Beans to keep the
programming interface fairly cleanly separated (though not as cleanly
separated as an HTML template approach), but like the template approach
there is quite a bit of overhead associated with updating bean values
from database values, then inserting bean values into the HTML stream,
even though JSPs are compiled at runtime.