RE: Making sure...

["Eyers, Daniel" <daniel.eyers@xxxxxxxxxxxxx>]

Agreed with EJB... Beans are definately the way to go... We use Ultradev to
help us with the bean code as well as embedded Java... It has improved our
productivity significantly.  We are not longer writing JSPs in notepad....
We looked at Websphere Studio, but we didn't feel it was as intuitive as
Ultradev... Of course, we have been using Dreamweaver forever...
 
dan
Dan Eyers
Honeywell International
Web Development

-----Original Message-----
From: DUCRET Gilles (GVA) [mailto:Gilles.DUCRET@lloydsbank.ch]
Sent: Wednesday, December 20, 2000 9:27 AM
To: 'JAVA400-L@midrange.com'
Subject: RE: Making sure...



Remark: 

One problem with JSP is that they are difficult to maintain. The best is
certainly 
not to write logic into a jsp file, but to delegate this logic (mostly
display logic) 
to a bean that is used by the jsp. Therefore, the only code you add to the
jsp is calls 
to that bean. 

If you read the sun blue print papers you'll find some documentation about
this: like presentation 
beans. 

About security: a jsp is compiled on the server, and the client only sees
the generated html 
file. I can't see how you could upload a jsp? You don't upload anything, all
the code runs on 
the server. 

-----Original Message----- 
From: Stone, Brad V (TC) [ mailto:bvstone@taylorcorp.com
<mailto:bvstone@taylorcorp.com> ] 
Sent: mercredi, 20. decembre 2000 14:51 
To: 'JAVA400-L@midrange.com' 
Subject: RE: Making sure... 


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



**********************************************************************
This E-mail and any files transmitted with it are confidential 
and intended for the exclusive use of the addressee(s) only.
You should not disclose its contents to any other person. 
If you are not the intended recipient please notify the sender
immediately.
**********************************************************************


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