RE: 520 pricing structure

> From: Bob Cozzi
> 
> >>I insist that except for the mot trivial of applications, straight
CGI
> >>with no templates is impossible to maintain in a production shop.
Do
> >>you disagree?
> 
> With no templates? Yes things like Net.Data, Perle and other pure CGI
> things
> that don't have GUI tools to work with them and their embedded HTML
are an
> interesting choice to say the least.

Yeah, that's my point.  Not to mention the fact that your RPG
programmers now also need to be HTML programmers.  And that making the
slightest change involves modifying and recompiling an RPG program.  All
of which makes a very unproductive environment.


> Programming language "X" with external HTML, such as is provided by
RPG
> xTools CGILIB and Mel's CGIDEV2 are another animal. I can maintain the
CGI
> programming language (whether it's RPG IV, C or XYZ) and the HTML
> separately just like we do with RPG and DDS for DSPF.

I agree again.  Any external library with a template-based HTML parser
significantly reduces the complexity of web development by providing a
layer of separation between the HTML and the RPG.  My biggest problem
with the RPG-CGI routines, though, is that the tags are usually
different from program to program.  One thing I'm not sure about is the
level of programmer control required, especially on input fields.  Am I
correct in assuming that a lot of it is under programmer control at
runtime?  For example, do you have to populate a variable with the
length of an input field.  With a good, thin JSP approach, you simply
identify the attributes of the fields and let the infrastructure format
the HTML tags.  I'm not saying you couldn't do the same with RPG-CGI,
it's just that I haven't seen anything like it in any of the packages.


> >From what I've seen with products like mrc-productivity.com stuff,
that
> generates server-side JSPs, that stuff appears faster than any
typically
> CGILIB or CGIDEV2 app. And I hate that. <tic>

Then you'd be frothing at the mouth if you saw the performance of the
thin-veneer JSP framework.  In essence, the framework does little more
than EBCDIC to ASCII conversion and then fires off the JSP.  It's
message-based, meaning no extraneous data gets sent (unlike many
EJB-based approaches), and the conversion code gets quickly compiled by
the JIT compiler to where the response time is nearly instanteous.

We freaked out a little when our first page took about 10 seconds to
load.  That is, until we realized we'd sent eight THOUSAND rows.  That's
table rows, not bytes.  Probably close to a megabyte of data.  We
trimmed the routine to send only 300 records, and got sub-second
response time (and normal-sized pages were just about immediate).

Joe