|
You'd rather use an applet instead of XMLHttpRequest objects?
How about a frame? Open the applet in a (hidden if there's no user interface) frame and your base page in another frame within the same frameset.
I still wouldn't do it. I'd store whatever info I needed to keep in a cookie that expires yesterday and let the applet reload whenever it needs to. The applet class file stays in the browser cache, so it won't have to be downloaded every time. The cookie disappears when the browser session ends.
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Holm
Sent: Friday, July 08, 2011 1:22 PM
To: java400-l@xxxxxxxxxxxx
Subject: Java Applet Staying Alive From Multiple Web Pages
Hi All,
I got a web application that allows user to execute many menu items which generate HTML pages back to the screen. Each interaction is a full request/response cycle to a backend Java tomcat server.
Challenge:
We understand the security requirements of applets. We have a servlet that is able to interact with the applet passing HTTP serialized objects back and forth. All that works fine until the page is refreshed and the applet is destroyed.
Does anyone have experience/best practices of what works best to keep a single applet alive for the duration of a web user session? I'm thinking we could do a popup window where the applet lives to keep it alive. Any other advice or experience?
Thanks, Paul Holm
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.