Re: Beginning web development -- WEB400

On Mon, 24 Sep 2001 10:15:32 -0500
 "Joe Pluta" <joepluta@PlutaBrothers.com> wrote:
> > Ok, Joe, explain to me how JSP is better for
> interactive web
> > pages than CGI.  No, you haven't in the past.  You've
> used a
> > lot of technical terms and jargon, but all in all your
> > outputting HTML with either tool.  How can one work
> better
> > than the other.  One may  be easier for you or I
> because we
> > are more familiar with it, but better, no.
>
> I get tired of arguing against your ridiculous assertion
> that just because
> you can do it in RPG, it's as good as doing it in Java.
> How silly.  The
> extension of that argument is that an MI implementation
> of an order entry
> program is as good as an RPG implementation.  Hey, you
> can do it!  And if
> that's your opinion, I hope I never have to maintain a
> project you worked
> on.

I didn't say it was as good in RPG.  You said it was better
with Java.  You have a bad habit of reading the opposite of
your words as mine.  And quit calling me riduculous and
silly.  It doesn't become a good Christian.  And comparing
RPG and MI is totally off base, and again a very poor
argument.

Anyhoo... more comments following...

>
>
> > A great way to explain this would be some code
> snippets.
> > Myself, and others, would love to see what you mean.
> Even
> > if it's just some psuedocode.
>
> In Java, I have a proxy object that has field objects as
> attributes.  These
> fields in turn have attributes, such as color and
> protect.  They also have
> attributes such as size and length.  When I want to
> output a field in a
> JavaServer Page, I do it as follows:
>
>   <%= proxy.getFormattedField("MYFIELD") %>
>
> This may translate to:
>
>   My field contents
>
> * or *
>
>   <input class=GREENREVERSE type="text" id=fld001
> name="MYFIELD"
>    value="My Field Contents" onkeypressed="uppercase();">
>
> This is entirely determined at runtime based on both
> dynamic and static
> attributes.

Yes this makes sense.  Simple question, where do you load
the attributes from.  The objects aren't just created with
them.  I'm guessing a table of some sort.  (The data has to
be stored somewhere, and loaded by your Java Class).

> Let's say I want to output a subfile.  I do it this way:
>
>   <%
>     while (proxy.nextRow())
>   %>
>
>   <%= proxy.getFormattedField("FIELD1"); %>
>   <%= proxy.getFormattedField("FIELD2"); %>
>   (...)
>
>   <%
>     }
>   %>
>
> And I can continue to extend my classes for whatever
> reason I need.  Say I
> want to override the method used for editing on a
> specific field.  I could
> do that easily:
>
>   <% setEditMethod("myuppercase"); %>
>   <%= getFormattedField("MYFIELD"); %>
>
> This is the elegance of using Java as both the formatting
> language and the
> control language.  There is a seamless interaction
> between the two.  You can
> do all of this in CGI, but you have to write new tags for
> each new feature,
> whereas I can simply add a method.

But in the bowels of your Java, where the real procedural
work is being done, it's writing out different tags for each
new feature as well.  It isn't coming out of thing air.

It seems that you're again comparing best case Java with
Worst case CGI (ie hardcoding everything).  And in this
case, I'd agree.  But if we compare best case with best
case, The real work being performed (outputting dynamic
HTML) is very similar.

And chances are that
> a new programmer is
> more likely to understand Java method calls than they are
> to somehow know
> your proprietary tag language.

Yes, and now we're back to your weighted argument of having
new staff, or staff to do each part of the project
(business/presentation).

A new programmer is also more likely to understand how to
use Net.Data as opposed to RPG as well.  But, let's get past
this by assuming we have a programmer who knows both Java
and the CGI programming language of choice.

>
> Anyway, I'm not going to convert anyone.  I've said my
> piece.

I hope you do convert some, and I agree JSP is a great tool,
Joe.  What I don't agree with is how you present your
arguments FOR it, and say that you "can't do this/can't do
this as easily" with CGI.  There are a million
Perl/PGP/ColdFusion programmers who would disagree with you
as well on how you present JSP/Java as the best solution.
Yet they would agree JSP is a GOOD solution.

>
> You all know my opinion on JSP vs. CGI.  CGI is fine, but
> flawed.  JSP is
> flawed, too, sure, but it's LESS flawed than CGI.  This
> is sort of like RPG
> IV vs. RPG III.  RPG III is perfectly fine for many, many
> things.  It's not
> until you need some of the more advanced features that
> you need RPG IV.  At
> least with RPG, you can buy a nice conversion tool, like
> CVTILERPG from my
> friends at Linoma, to convert your programs.  Once you've
> wandered down the
> CGI path, it's hard to make the move to JSP.

Why would I use CVTILERPG.  I have CVTILEFMT, and it's free.
:)  (sorry Bob L...)  Used by thousands of programmers
across the world.

The move from CGI to JSP isn't hard, if we had the right
tools for the platform we are working on.  I've already
stated my gripes with Websphere and IBM not making tools
like Apache and Tomcat (the REAL apache) available on
OS/400.  It's the main reason I stick with Linux and Win to
mess around with Java.

Brad
www.bvstools.com