RE: Making sure...

["Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>]

I guess I shouldn't be using IBM's examples then.  I'm finding a lot of
programming flaws in them, like it was written for programmers who have only
done RPGII.  

Why do JSPs scare me?  WEll, we've been through this before on another list,
but it seems to me that it is easier to upload a jsp file that could do harm
(same as a net.data macro, ASP, or anything interpreted) than it would be to
install a compiled CGI object (RPG, COBOL, etc). 

I must admit, I'm working on the servlet example from IBM that reads from a
browser.  I must have removed half of the code already.  Nasty programming.
Lots of unneeded "ifs" and "hold variables" to check contions.  yuck.  

I haven't even touched on DB access yet.  Im sure that will be the defining
moment because it can't be easier than eRPG. :)

Brad

> -----Original Message-----
> From: Joe Teff [mailto:JoeTeff@earthlink.net]
> Sent: Tuesday, December 19, 2000 9:57 PM
> To: JAVA400-L@midrange.com
> Subject: RE: Making sure...
> 
> 
> >JSPs scare me.  Seems there could be a security risk, but I 
> won't know
> until
> >I play more.
> 
> Why? JSPs actually get compiled into a servlet at load time, so they
> function
> exactly the same as a servlet. What is does is allow you to 
> separate the
> static HTML from the dynamic code. Much like Net.Data. In 
> eRPG I store the
> static HTML in files and then read it into the CGI program. 
> Really the same
> result except with JSP there are design tools emerging 
> (WebSphere Studio
> and Ultradev to name a couple) that allow you to design your JSP pages
> WYSIWYG
> with placeholders for the Java (JSP tags).
> 
> >Servlets.  LEt's just say that at this piont comparing to 
> e-RPG to servlets
> >is like comparing flying a paper airplane to a 747 as far as 
> complexity to
> >do something simple like read data from a web page.   But 
> maybe one day
> that
> >will change.
> 
> I think they are very similar in many regards. Getting environmental
> variables
> is a method call rather than a subprocedure call (assuming 
> you encapsulated
> the C APIs in a service program). You can simulate most of 
> the request and
> response methods with subprocedures if you want. Doing things 
> with session
> is nicer. They do scale better because of spawning threads 
> for each request.
> Overall, I see many more similarities than differences. One 
> advantage is
> standardization. Everyone uses the same objects and methods 
> where as in RPG
> is varies depending on how the subprocedures and service 
> programs are set
> up.
> The large class libraries available from Sun and IBM provide 
> for a lot of
> functionality right out of the box.
> 
> >Now I challenge all of you to try out e-RPG.  :)
> 
> I have. In fact I did that based on your MC articles before 
> your book was
> published.
> 
> Joe
> 
> +---
> | This is the JAVA/400 Mailing List!
> | To submit a new message, send your mail to JAVA400-L@midrange.com.
> | To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to 
> JAVA400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner: joe@zappie.net
> +---
> 
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---