Re: Vendor presentations

This sounds like someone needs to do a fair benchmark of the various techniques.
CGILIB in xTools
CGIDEV2
JSP
RPGsp
RSP

And see where each is fast, slow and needs improvement.

Then they also need to be compared to the various code generators our there,
such as WebSmart, MRC and the others I'm forgetting to mention.


-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.

-----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.