Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: tools for programming applets Date: Mon, 23 May 2011 23:01:57 +0000 (UTC) Organization: UK Free Software Network Lines: 53 Message-ID: References: <7ae454dc-7844-4a33-8f04-c1393f931365@glegroupsg2000goo.googlegroups.com> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1306191717 30836 84.45.235.129 (23 May 2011 23:01:57 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Mon, 23 May 2011 23:01:57 +0000 (UTC) User-Agent: Pan/0.133 (House of Butterflies) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4500 On Mon, 23 May 2011 12:32:11 -0700, horos22 wrote: > > Think about it this way: an applet is a client in the same sense of the > word as a browser is a client. > About the only way I can think of to meet your requirement is to start by coding the applet so it can be run both as an applet and as a free- standing client, i.e. it must implement the applet interface and have a normal main() method which will invoke the applet methods when run outside a browser. This lets you test most of the applet's operation against a remote server *but* it will still need to be loaded from the server to confirm that it works correctly when invoked as an applet by the target browser(s). > Instead of serving up html, you serve up code. This code is run locally, > with potential input from the server, and it passes back output directly > to the server. > You're missing a major point. The applet *must* be downloaded at least once by the browser and again each time the browser's cache is cleared. The browser is the only client of the web server. The applet is just something the browser can download from the web server and use as an enhancement to let it communicate with a second (non-web) server sitting alongside the web server. > Now, in your paradigm of development, it may be helpful to *think* of > the applet as a server-side object > Not 'helpful', but essential since it must be downloaded from the host computer by the web server that the user's browser is talking to. >it really is a client - one hosted on a server, but a client nonetheless. > Yes, but its not a client of the web server, just a mandatory payload that must be requested from a web server sitting alongside its target application server. Them's the rules and you're stuck with 'em. I really don't see what you're kicking about, though. Its pretty trivial to take an archive file containing the target web and application servers and install copies on your desktop box. Since you're not concerned with response time during development, even a fairly feeble desktop box should cope: I've run Tomcat alongside the web browser on an NT4 box with no problems and currently am running Apache, PostgreSQL and a full set of Java development tools on a 512MB, 866MHz P3 box under RedHat Linux (Fedora 13). Both set-ups handled development and testing quite adequately. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |