Re: tools for programming applets
Alessio Stalla wrote:
Guys, sorry, but you're completely nuts. Once more I understand why
Java has got the reputation of being bloated. We should remember that
Java is not necessarily targeted only at big corporations and multi-
million projects! The OP asked how to do a certain thing. Telling him
how a Fortune 500 company should do it is not going to help him.
Besides, I don't think even a Fortune 500 company should clone the
whole production server just to test one *applet*!
Huh? "Fortune 500 company"? Where's your head, dude? It takes twenty
minutes and about 50c worth of disk space to clone the server. I do it all
the time at home in my practice work. That's one individual person, not even
a company, let alone a Fortune 500 company. Get real.
To answer directly to the OP question: there are a few ways you can
test your own modified applet against your production server.
1) you can run the applet as a standalone application: either coding
(e.g. a JFrame to contain it) or using something like Oracle's
AppletViewer. This is feasible only if the applet does not interact
with the surrounding page.
Suggested upthread, but only partially useful as not all applet behaviors can
be tested this way.
2) signed applets can bypass security restrictions. So you can run
On the localhost, yes. It doesn't change the restrictions on which server they
can communicate with.
The tutorial explains this:
"An applet can communicate with server applications that run on the same host
as the applet."
<http://download.oracle.com/javase/tutorial/deployment/applet/server.html>
"Signed applets operate outside the security sandbox and have extensive
capabilities to access the client."
<http://download.oracle.com/javase/tutorial/deployment/applet/security.html>
your (signed) applet on a page loaded from localhost and still connect
to the remote server. Or, if you *really* need the applet to run on
the production page itself, you can probably use something like
Greasemonkey to patch (your client-local version of) the page to
include the applet. Needless to say, the latter option could be a
violation of the site's terms of use, and it's unnecessarily
cumbersome, so avoid it unless it's the only option left.
The applet still has to communicate with the server from which is was loaded,
and no other.
To everyone else: applets *are* client-side. Really, I can't imagine
why you think otherwise. Yes, they are downloaded from a server; so
They are a special component that talks to a special application server, not a
client of the web server, as explained upthread.
what? Most software nowadays is downloaded from somewhere the first
time. But they run on the client, and only talk to the server via
remoting, RPC, SOAP or whatever else. Or do you really believe that
e.g. Flash is server-side?
Sorry for being a little aggressive, but I can't really understand why
there are ~50 posts sponsoring the big costly solution and ~0
suggesting the practical one.
Because the solution is neither big, nor costly, and is, in fact, much LESS
expensive than testing on the production box. Risk has a cost, duh. Talk
about how inexpensive development and testing on the production server are
when you've brought it to its knees and the client is out of business for a
day while you try to undo the damage done by your insane irresponsibility.
Why do you guys latch on to this "big, expensive" rhetoric as if there were
any merit to it whatsoever? It's been pointed out before that that is false
reasoning. What is this, repeat the Big Lie (without evidence or supporting
logic) long enough and this intelligent group of software engineers are
somehow suddenly going to believe it?
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg