Re: Vendor presentations

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

I don't understand this point, Nathan. A bean in its simplest form is really
nothing more than a structure of pointers, either to data or to methods.  In
a JIT compiled environment, the methods all become compiled down to the
metal, exactly the same as a compiled language.  So the only overhead is
converting your database data from EBCDIC to Unicode (for storage in the
bean) and then from Unicode to ASCII (for the output to the HTML data
stream).  This is roughly double the overhead for straight EBCDIC to ASCII
that you can do in RPG-CGI for character data, but other than that, I see no
difference between the two approaches.

How much that matters depends on how much data you convert, obviously.  It's
a fair issue: how much of a given browser page is computation, how much is
database I/O, how much is conversion, and how much is overhead.  JSP has the
built in double overhead I talked about, and if this becomes significant
there probably needs to be at least a passing thought paid to the once
absurd notion that perhaps we should be storing character data in either
ASCII or Unicode!  In that case, BOTH approaches would benefit, but is the
benefit significant enough?

Interestingly enough, this will become more apparent as AJAX is used more to
update small pieces of a page rather than writing the entire browser page
every time.

Joe


> From: Nathan Andelin
> 
> 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.