RE: Beginning web development

Hello Joe,

You wrote:
>Bunkum, Simon.

I see your bunkum and raise you bollocks!

This is the beginning of an argument much like the one you and Brad Stone
entered into a few months back on the Java list.  You accused Brad of
changing the argument as he went to suit his purposes.  His approach must
have made quite an impression because here you are trying the same trick on
me.

One must look beyond the statements and look for the motive.  It is in your
interest to discredit a non-JSP approach because you have a vested interest
in a JSP-based approach.

I did not say that JSPs were innappropriate.  I simply pointed out that you
were perpetuating a myth and explained why you were wrong.  You then
respond with a completely new argument about why JSP is better and that
writing a replacement Application Server would involve a lot of work.  Both
points I actually agree with.

At the risk of filling the list with more opinion-as-fact let's deal with
your NEW arguments.

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

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.
If you need the full feature set of JSP then you would indeed be foolish to
write a replacement environment.

The benefit is in making better use of your system resources.  JSP requires
an Application Server which generally requires an HTTP Server.  While an
HTTP Server may be manageble on most AS/400s a JSP Application Server is
not.  They are generally very hungry on resources and frequently require a
major hardware upgrade to make them run acceptably.  Even you in your
approach have realised that and use HLLs as the background processor.

Also, the specific requirements of a given "get-it-on-the-Web" project may
not warrant the added expense of additional hardware, software, and
education.  The  benefit is in using tools you already understand to meet
the requirements of a project that doesn't warrant learning another
language or spending money on more gear.  It is a valid approach and one
you attempted to discredit with a false statement.

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

Now that IS a specious argument! and it's not worthy of further comment.

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

I suspect I have been using Java and JSP for longer than anyone on these
lists.  I started with Java in 97.  I am well aware of the capabilities of
both environments.  However, I am not blinded to alternatives.

I too teach Java to RPG and COBOL programmers and the syntax is the easy
part (as you yourself have argued in the past).  I do not believe you get
average RPG and COBOL programmers upto speed with all that Java and JSP
entails in a week.  It is possible that you get them productive with your
tool in that t
e however I fail to see the relevance.  I never suggested
writing a replacement for an Application Server, merely a
search-and-replace engine which IS trivial code and would take a lot less
than a week to implement.

If you are concerned about a 'non-standard' syntax there is no reason why
an HLL could not process the standard JSP tags (Oh, which version of the
"standard" tags did you have in mind?)  but that removes us from my
original point of trivial scan and replace.

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

Again, you seek to expand the argument into territory not covered by my
original comment.  JSPs don't provide caching, the Application Server does
that (often in conjunction with the HTTP Server).  Besides, simple caching
of common pages or data is fairly easy using *USRSPC and *USRIDX objects,
or an array of pointers to dynamically allocated storage, or a linked list
of file buffers, or any one of a number of other approaches.  However,
caching has nothing to do with the original argument.

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

I didn't suggest writing such a replacement so again you put words in my
mouth to further your own design.  You also confuse JSP and the Application
Server (I suspect deliberately in order to support your case since I am
sure you do understand the difference).  I agree a full replacement for an
Application Server is not a trivial exercise but I never suggested that
course.

Even a simple search-and-replace function can read an <ITERATE> tag and
perform looping or an <IF> tag and perform conditional tasks.  It IS
trivial when using literals (e.g., <ITERATE 10> or <IF
CONDÒfile×CUSTMAST'">, it gets harder if you want to support variables
and embedded code.  Again, I never suggested that  (Have you got that yet!)

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

Ah! Discredit my argument by suggesting I don't know what I'm talking about
or have limited experience with Java and JSP.  You used that one on Brad
too as I recall.  In his case it may have been accurate but in my case it's
not.

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

That's another approach you used on Brad.  I am well aware that JSPs are
capable of more but the ESSENCE is exactly as I stated.  The code generated
from a JSP reads the original file of HTML and builds a new stream by
replacing magic markers with data from a Bean.  Yes, you also have control
constructs, and can embed code, but in most cases the real work is done by
a backend Java program and the JSP simply formats the res
t.  Regardless
of how much additional function is added to JSP, the core function is an
HTML pre-processor.  All the rest is built on that ability.  Using a Bean
to provide dynamic data is simply a disguised call-back.  A call back is
easily implemented in any language that supports function pointers.  A
requirement for function pointers would indeed restrict the possible HLLs
one could used.  You would be limited to C, RPG IV, ILE COBOL.  (Dropping
into sarcasm so I think I'll cease.)

Over to you.  Let's see how you misconstrue these comments.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   «»
«» Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   «»
«»                                                           X    «»
«»               ASCII Ribbon campaign against HTML E-Mail  / \   «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»