RE: Beginning web development -- WEB400

Simon, let's strip this down quickly.  There are several basic approaches:

1. CGI with HTML formatting embedded in the program
2. CGI reading external HTML and scan and replace
3. A fully functional page processor is something other than Java
4. Servlets with HTML formatting embedded in the program
5. JavaServer Pages

Option one and three are bad because of the embedded formatting.  Option
three is ridiculous, for the reasons I pointed out in my previous post.  So
it's down to option two, which you like, and option five, which I like.

-----------

Before I address that, I want to quickly deal with your woefully incorrect
statement that I promote JavaServer Pages because I use JavaServer Pages.
You have it nearly completely backwards.  My PSC400 product uses JSP for the
same reason I promote JSP: it's the best solution, in my opinion.  However,
I have no vested interest in people choosing one way or the other, because I
don't sell JSP web applications.  I sell a complete, self-contained toolset
and runtime that automatically converts existing 5250-based programs to use
the web as an interface instead, thereby avoiding the interactive tax.
There is no programming involved - UNLESS you choose to make the interface
more "webby", at which point you can then modify the JSP.  Because my
solution uses JavaServer Pages, the generated pages can be maintained by
anybody who knows the syntax.  If I could do this as easily with CGI, I
might, but I found it much easier to develop using servlets and JSP.

----------

Back to the discussion.  You originally took offense to my statement:

"COBOL CGI is quicker to implement, but in
my opinion a little less flexible, because all the user interface code is
embedded in the COBOL programs.  With Java Server Pages, the JSPs actually
format the data, kind of like the DDS for a display file.  You can change
the look of your application without actually changing the COBOL code."

You got all hot under the collar, complaining that I was perpetuating a
fallacy, even though I clearly indicated it was my opinion.  You went on to
say that you could write a CGI cut and paste routine with the same
capabilities as JSP:

> It is trivial for a CGI program written in RPG, COBOL, or whatever HLL
> takes your fancy, to read the HTML from a file and use scan and replace to
> insert dynamic data.  In essence that is exactly what JSPs do.

Silly me.  When you said that "in essence that is exactly what JSPs do", I
took this to mean that JSPs are in essence a scan and replace of HTML.  And
since I know that to be false, I presented a review of the architecture of
JSP vs. CGI.  I pointed out the differences between JSPs and a simple cut
and paste.  I didn't put words in your mouth.  I responded to what I saw to
be a somewhat erroneous statement.

It was especially erroneous to me because when I think of a web application,
I think of something that requires interaction with the user, and that
requires a lot more than simple cut and paste.  But upon reading your latest
missive, I understand that this is exactly where we digress.  You write:

> Firstly, I am not suggesting that people eschew JSP in favour of a
> roll-your own CGI.  Merely that it is possible to create dynamic pages
> using an HLL and that JSP is not a requirement.  Secondly, most
> sites don't
> use even 50% of the capabilities of JSP.  They use them for the simple
> purpose of dynamically formatting data.  That IS trivial to code
> in an HLL.

I apologize.  I didn't realize that to you a web application is one that
outputs formatted data.  I was referring to web applications that actually
interact with the user.  To properly format forms, change styles, etc., on
the fly, and act as a true user interface, it requires far more work than
simply cutting and pasting from an HTML page.

For example, to allow a field to be "protected", you need to choose whether
you're going to use the "DISABLED" attribute in the HTML or simply output
the actual data (the latter is my preferred method, as it reduces the amount
of data sent to the browser).

Or, how about a "simple" input-capable field.  You have to determine the
length of the field, which should include any editing characteristics.
You'll need a name for the field, and, depending on whether you support
non-trivial field characteristics, you'll need a unique ID.  You'll need a
way of determining the colors - for best effect, you should probably use a
cascaded style sheet.  You may have to change the colors dynamically to
provide visual cues for errors.  You may need to dynamically set the focus
on a field (such as when it is in error).

All of that is for a simple input field.  Things get far more complex when
you're thinking of things like select lists, checkboxes, or radio buttons.
To determine all these values on the fly in a CGI program is a little more
than a simple cut and paste.

---------

Anwyay, we seem to agree that CGI is not a JSP replacement.  Your argument
is that CGI can do some things as easily as JSP.  To that statement, I
conditionally agree.  If you're basically outputting pretty data on a web
page, CGI is a good alternative.  If you're actually communicating with the
user in an actual application, then JSP is a far better approach.

My concern is that, if someone is actually going to develop a web
application, even if it starts as primarily output-only, they are likely
going to need to communicate with the end user some day.  And in that case,
the work spent on CGI is going to be less transferable than if they'd
started from the ground up with JSP.

Joe Pluta
Pluta Brothers Design, Inc.
www.plutabrothers.com