Nathan Meyers writes [in response to Matt Zagni]:
> All applets are browser-based, unless there's some subtlety in your
> statement I'm missing. But applets interact with users through a GUI...
> windows, pointers, menus, etc. Imagine rewriting your applet without
> being able to use any classes from the java.awt or javax.swing packages.
> That's basically what you have to do.
That's not completely true. There are several commercial solutions
that allow you to port some types of graphics-intensive applets to
servlets with reduced effort.
The basic idea, shared as far as I know by all such packages, is to
force the "server-side applet" to draw its UI elements into a scratch
buffer. Then, at programmer-specified points in the "server-side
applet," a GIF or JPG is generated from the scratch buffer and is sent
back to the browser along with forms entries to provide the next stage
of input.
Obviously this doesn't work for all applications, and it does require
some recoding, but it's probably not as bad as "without using java.awt
or javax.swing." See Jason Hunter's "Java Servlet Programming"
(O'Reilly) for a brief intro to this stuff. Hunter also gives a toy
example of "server-side applets" using only the standard Java classes
and a few from com.sun.*. Sorry I can't give more details; the book's
at home.
> You can get fancy: divide your application into GUI components that run
> as an applet on a browser, non-GUI components that run on a server, and
> use RMI to connect the two.
Matt, if your goal is to prevent decompilation, I think this might be
the best approach. In my experience, the applet-servlet model (an
applet-based GUI and data validator which talks to a servlet-based
processing engine via RMI) is the best way to write complex web-based
applications anyway, even when code security is not an issue.
There are portability concerns with RMI, but if your user base can all
run Activator (or, with a bit more effort, stand-alone Navigator),
your code will be clean and remarkably fast.
In your case, you would want to decompose your application into the
portions that require code security and those that don't. The secure
classes could then be created within a servlet, and the only
applet-servlet communication would involve those classes. All other
portions of your applet could remain the same. Of course, poor design
at any point in the conversion process could lead to ugliness fast, so
you may want to find someone to help you avoid poor design choices.
Best,
daniel dulitz
Valley Technologies, Inc. Peak Performance Real-Time DSP
State College, PA
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
