web page communicating with an applet

[kenvc]

I'm looking for ways to communicate to a running applet, from other
parts of the web page that are running standard HTML/javascript. The
context is that I have an existing Swing desktop app that I am
converting to run as an applet, but I want to move all the navigation
to HTML, while using existing forms in the applet. This is going to
let me gradually transition the Swing app to a web-based application,
reusing Swing forms inside a browser window until I have a chance to
rewrite them all using proper web development technologies. As a user
clicks on different navigation links in the HTML portion of the
screen, I want it to notify the running applet to switch to a
different form.

I can see different ways to approach this:

1. Ideally I'd like this to all happen client-side. Unfortunately (as
far as I know), an applet has only a single entry point (init) and
there is no way for an applet tag to invoke a method on a running
applet. (Right?) My application (applet) is going to be fairly big,
so I don't want to restart it every time just to display a new form.

Given these limitations, I thought I might have a small (hidden)
applet that the navigation invokes, and passes parameters telling it
what form is desired. Then applet-to-applet communication allows the
small applet to communicate with the (big) running applet, telling it
to switch screens.

2. If client-only communication can't be used, the other alternative I
can see is to have the navigation invoke a servlet, and then the
servlet send a message to the applet telling it what form to show.
How best to send this message, considering that my clients are running
over the Internet, through their own firewalls, etc.? I would guess
my communication needs to be tunneled through HTTP in order to work
through client firewalls, but I am not sure the best way to approach
this.

Thoughts? Suggestions?
Ken Van Camp

 

[angrybaldguy]

I'm looking for ways to communicate to a running applet, from other
parts of the web page that are running standard HTML/javascript.  The
context is that I have an existing Swing desktop app that I am
converting to run as an applet, but I want to move all the navigation
to HTML, while using existing forms in the applet.  This is going to
let me gradually transition the Swing app to a web-based application,
reusing Swing forms inside a browser window until I have a chance to
rewrite them all using proper web development technologies.  As a user
clicks on different navigation links in the HTML portion of the
screen, I want it to notify the running applet to switch to a
different form.

I can see different ways to approach this:

1. Ideally I'd like this to all happen client-side.  Unfortunately (as
far as I know), an applet has only a single entry point (init) and
there is no way for an applet tag to invoke a method on a running
applet.  (Right?)  My application (applet) is going to be fairly big,
so I don't want to restart it every time just to display a new form.

Javascript can invoke methods on applets. See <http://
www.codestore.net/store.nsf/unid/DOMM-4U8FM6/> for an example (known
to work on Safari and Firefox; I don't have IE here to test with).

-o

 

[Andrew Thompson]

I'm looking for ways to communicate to a running applet, from other
parts of the web page that are running standard HTML/javascript.  

It is (relatively) easy to use JavaScript to
call applet methods, and access attributes of
that are public.

Check out Real's HowTo for the Java/JS interaction
<http://www.rgagnon.com/howto.html>
(The JavaScript | Interaction with Java section)
...there are several nice examples.

OTOH ..(1)

..The
context is that I have an existing Swing desktop app that I am
converting to run as an applet, but I want to move all the navigation
to HTML, while using existing forms in the applet.  This is going to
let me gradually transition the Swing app to a web-based application,
reusing Swing forms inside a browser window until I have a chance to
rewrite them all using proper web development technologies.  As a user
clicks on different navigation links in the HTML portion of the
screen, I want it to notify the running applet to switch to a
different form.

I can see different ways to approach this:

1. Ideally I'd like this to all happen client-side.  Unfortunately (as
far as I know), an applet has only a single entry point (init) and
there is no way for an applet tag to invoke a method on a running
applet.  (Right?)

There is no way to change the tag itself,
but that is not a problem if the applet
provides public methods to *set the parameters.*

.. My application (applet) is going to be fairly big,
so I don't want to restart it every time just to display a new form.

Makes sense. But ..(2)

Given these limitations, I thought I might have a small (hidden)
applet that the navigation invokes, and passes parameters telling it
what form is desired.  

I do not quite understand how you think an
intermediate applet will help here, but
check out the examples linked above for
probably better ways to communicate between
HTML links and the main applet.

..Then applet-to-applet communication allows the
small applet to communicate with the (big) running applet, telling it
to switch screens.

(1) ..if the 'alternate applet' *was* the
navigation, it could communicate directly
with the main applet, here is another e.g.

Thoughts?  Suggestions?

(2) Something smells wrong with this entire approach.

What happens halfway through the transition?
Is there a directly linear flow through the
'forms' the user is seeing? What is the risk
of them continually jumping into and out of
the applet between entire HTML forms?

Also, applets are usually a lot harder than
they might seem. Do you deal with a (small)
set group of browsers, and have control over
the JRE they run? Applet/browser interaction
problems can be a nightmare.

And since I'm here - it is a pity to hear
of yet another Rich client being converted
to plain ol' HTML forms. Still, if they
do the job that needs doin', it does save
having to load a JRE, or even install one..

 

[Andrew Thompson]

..
Javascript can invoke methods on applets.  See <http://www.codestore.net/store.nsf/unid/DOMM-4U8FM6/>

I will probably have people scowling at me
for mentioning this, but the big G stuffs
most long links unless you do something like..

http://www.codestore.net/store.nsf/unid/DOMM-4U8FM6/

This is not any sort of usenet standard,
indeed, the way you posted that link should
work in most known news clients.

( I thought I'd mention it, since all three
of the posters so far in this thread, are
using the 'accursed WITUN' that is just
about to destroy the sig. delimiter by
removing the final ' ' of '-- '

 

[Andrew Thompson]

On Dec 23, 5:01 am, (e-mail address removed) wrote:
...

And of course, dope that I am, I failed to
realize that while the *original* link you
posted 'rendered oddly', it was still a
valid/clickable link nonetheless.. (..time
for sleep)

 

[kenvc]

First of all, thank you for the quick responses! Both of the above
two posts have shown me some good approaches that seem to work.

Second, I'll take a moment to respond to Andrew's others comments:

(2) Something smells wrong with this entire approach.

What happens halfway through the transition?
Is there a directly linear flow through the
'forms' the user is seeing?  What is the risk
of them continually jumping into and out of
the applet between entire HTML forms?

This is a valid point, and one we have discussed. At this juncture we
are just starting on technical feasibility investigations, and we have
not actually started deciding what screens to rewrite when. Careful
analysis of workflows will need to be conducted so the "halfway" point
doesn't lead to a confusing mixture of applets and web forms.

Also, applets are usually a lot harder than
they might seem.  Do you deal with a (small)
set group of browsers, and have control over
the JRE they run?  Applet/browser interaction
problems can be a nightmare.

This is another good point, and one I'll confess to being less
knowledgeable about, so thank you for the heads-up and I'll try to do
more homework in this area. To answer your question, though, I do
have a relatively small base of users (less than 200), and we do have
the ability to require Java 6 runtime. We can also limit their
browser choices to only a few supported versions.

And since I'm here - it is a pity to hear
of yet another Rich client being converted
to plain ol' HTML forms.  Still, if they
do the job that needs doin', it does save
having to load a JRE, or even install one..

Distribution of our app is the biggest argument for conversion to
web. We work in a dynamic industry where our customers expect
relatively quick turn-around on features. We use Java Web Start to
distribute our desktop application today, and clients object to
frequent new version distributions... but they complain loudly if the
new versions don't keep coming. These objections go away if all the
changes happen on a web server, where upgrades are transparent to the
user.

Thanks for your thought provoking comments.
Ken

 

[Andrew Thompson]

...I do
have a relatively small base of users (less than 200), and we do have
the ability to require Java 6 runtime.  We can also limit their
browser choices to only a few supported versions.

That will make it significantly simpler.
Try to make sure you have access to the
browsers it is supported on, for testing.

Distribution of our app is the biggest argument for conversion to
web.  We work in a dynamic industry where our customers expect
relatively quick turn-around on features.  We use Java Web Start to
distribute our desktop application today, and clients object to
frequent new version distributions...

Had you considered breaking up the app.
into smaller chunks? At least then,
the user only has to download the
changed jars(s), not the entire app.

Also - webstart has a 'lazy download'
facility that might help, as well as the
DownloadService, in which the app. can
take direct control of the downloads (and
might potentially - check for new classes
at the start-up, if found, download them
in the background, then when done, inform
the user that 'an update is available -
click the button to change to new version'
which would basically bounce them out of
the webstart app. then restart it immediately).

It has been a while since I dealt with the
DS, here is an example I was working on..
<http://pscode.org/jws/cache/#eg8>

Two further points while I remember:

1) Caching of classes is one of the thorniest
applet problems. Some browser's will do it
when you don't want, others won't do it when
you do want caching to happen.

2) Since 1.6.0_10+, applets can hook
directly into the JWS API. This provides
several advantages, including the increased
control over resources & resource caching.
<http://java.sun.com/developer/technicalArticles/javase/6u10_applets/>

 

[Arne Vajhøj]

I'm looking for ways to communicate to a running applet, from other
parts of the web page that are running standard HTML/javascript. The
context is that I have an existing Swing desktop app that I am
converting to run as an applet, but I want to move all the navigation
to HTML, while using existing forms in the applet. This is going to
let me gradually transition the Swing app to a web-based application,
reusing Swing forms inside a browser window until I have a chance to
rewrite them all using proper web development technologies. As a user
clicks on different navigation links in the HTML portion of the
screen, I want it to notify the running applet to switch to a
different form.

I can see different ways to approach this:

1. Ideally I'd like this to all happen client-side. Unfortunately (as
far as I know), an applet has only a single entry point (init) and
there is no way for an applet tag to invoke a method on a running
applet. (Right?) My application (applet) is going to be fairly big,
so I don't want to restart it every time just to display a new form.

Given these limitations, I thought I might have a small (hidden)
applet that the navigation invokes, and passes parameters telling it
what form is desired. Then applet-to-applet communication allows the
small applet to communicate with the (big) running applet, telling it
to switch screens.

That is one way of doing it.

2. If client-only communication can't be used, the other alternative I
can see is to have the navigation invoke a servlet, and then the
servlet send a message to the applet telling it what form to show.
How best to send this message, considering that my clients are running
over the Internet, through their own firewalls, etc.? I would guess
my communication needs to be tunneled through HTTP in order to work
through client firewalls, but I am not sure the best way to approach
this.

If you are to be firewall friendly then push needs to be simulated
via poll (over HTTP).

With a sufficient small number of users and a sufficient poll
interval then that will work.

I think I would go for the server side solution. It is under your
control. Multiple applets in same page communicating may hit
problems with browser and java differences.

Arne