RE: Beginning web development

Bunkum, Simon.  Certainly, you can write a pseudo-page server that reads
through "code snippets" or even through entire HTML files and does some sort
of scan and replace to generate code.  You would have less than 50% of the
capability of a JSP, it would be non-standard, and you'd have to maintain
the cut-and-paste code.  So what's the benefit of reinventing your own
sub-standard wheel?

Heck, why not write a program that directly executes RPG source code, rather
than go through the cumbersome old compiler?  It's as good an idea as
writing your own JSP processor.

The only reason not to use a Java Server Page is a refusal to learn even the
basics of a very simple language like Java.  I teach RPG and COBOL
programmers how to build true client/server applications using servlets in
one week.  I suspect writing a complete parsing server that has all the
support of a JSP would take at least that long.  And again, that sort of
application is non-standard, so that means somebody using it has to learn
your particular syntax, rather than using something industry standard.

Also, all servlets in a web application share persistent memory within the
JVM, which allows them to do a lot of sharing and caching of information -
caching that you would have to manually code for any form of CGI.

Finally, your COBOL-driven HTML scan and replace doesn't support the basic
Java syntax - looping, conditional code, and the like - that can be used
inside of a JSP to execute code and communicate dynamically with the server.
Instead, you can only send data to the HTML data stream and can only receive
it from a POST.  With a JSP, I can - while the page is being generated! -
interactively change the very generation characteristics of the code in
response to other events in the page, or even in response to other events in
the system.  Of course, you can do that, too, but if you have added loops
and branching to your "snippet syntax", you're writing your own language.
While occasionally necessary - I've written several in my career - it's
absolutely not warranted in this case, when a perfectly good one exists, and
writing an interpreter for such a language is hardly "trivial", as you
suggest.

While COBOL CGI may be easier for the very simple type of cut and paste HTML
you may be familiar with, JSPs are quicker, easier and faster to implement
for anything of a non-trivial level of complexity.  To top it all off, any
Java code used in a JSP can later be encapsulated into a Java class and
folded back into the servlet.

If you think that the essence of a JavaServer Page is just cutting and
pasting into HTML, then you might want to spend a little more time with
them.

Joe


> -----Original Message-----
> From: web400-admin@midrange.com [mailto:web400-admin@midrange.com]On
> Behalf Of Simon Coulter
> Sent: Friday, September 21, 2001 5:43 PM
> To: web400@midrange.com
> Subject: RE: [WEB400] Beginning web development
>
>
> 
> Hello Joe,
>
> You wrote:
> >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.
>
> I can't this fallacy pass.  There is no more requirement for CGI programs
> to embed HTML (regardless of language) than there was for Java to embed
> HTML.  If you recall the history of servlets you'll find that is how they
> started. Host Java code would write HTML to the the web server.  That was
> silly for obvious reasons and the HTML was removed and abstracted via JSP
> (and other techniques).
>
> 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.
> If you look
> at the generated code you'll find they read the orginal HTML and scan for
> magic markers and replace them with data from a Bean.