[jdjlist] RE: Pushing data to a browser

Greg Nudelman Thu, 13 Jun 2002 10:43:57 -0700

It helps if the applet code is "light". However, the time overhead to having a VM startup and load the code is significant, esp. on older machines. If you can guarantee that all your users have a uniform browser/OS, then applets can be helpful, otherwise, watch out!

>You don't need to make it invisible, you don't need to put it into a frame. Just make the applets width, height = 1. >That's invisible enough.

Something to consider: if you're not using a frame to hold the hidden applet, the applet would have to be re-initialized by the VM every time the user moves to a different page.

>With the javascript approach, Netscape6 will put every request into the history of the browser. So as your user tries >to go back they just keep getting the last request of your javascript.

Sorry, I disagree -- not POST requests, those are never cached.

Perhaps I did not make clear the JavaScript method I am using:

//simplest timer -- it works

var messageTimerIntervalID = null;

function messageTimerStart(looptime){
messageTimerIntervalID = setInterval('getMessages()', looptime);
}

function messageTimerStop(){
clearInterval(messageTimerIntervalID);
}

messageTimerStart(60000);

function getMessages(){
    document.FEngine.TransactionID.value = "GET_MSG";
    document.FEngine.LoginID.value = User_ID; //or whatever data is part of your "get messages" transaction
    document.FEngine.target = "MessageFrame"; //change the frame for your request
    document.FEngine.submit();
}

All I'm saying is that this code will take AT MOST 2 hrs to polish. I am not saying JS is better then the applet, but I am a big fan of a concept of "Appropriate Technology". IMHO, I would not mess with applets if all you need them for is web messaging. They create as many problems as they solve.

Greg

-----Original Message-----
From: Mike Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 6:10 AM
To: JDJList
Subject: [jdjlist] RE: Pushing data to a browser

I tend to disagree. I am using applets to do just this sort of thing in an enterprise web application. The applet code to do this would be rather light. I have 4 of these types of applets in one jar and its ~ 23k. That's light compared to some images that people download on pages.

With the javascript approach, Netscape6 will put every request into the history of the browser. So as your user tries to go back they just keep getting the last request of your javascript. Also lots of companies prefer noframes? Not exactly sure why, but they do.

You don't need to make it invisible, you don't need to put it into a frame. Just make the applets width, height = 1. That's invisible enough.

Secondly, I found that using https with Netscape6 causes problems if you use javascript to invoke methods in the applet to do your querying. Better to let the applet load and then in a thread have it do the querying all within the applet. Once the applet gets what it wants, you can call from Java into Javascript or use the applets context to do a redirect.

Good Luck
--ekiM

On Wed, 2002-06-12 at 18:00, Greg Nudelman wrote:
Hello Roger,

There was a lot of discussion about this just recently.  I think the
"easiest" way to accomplish what you want is a browser-driven query of the
messages on the server through JavaScript timer function.  Applets create
all sorts of problems, from not being able to run in certain browsers, to
being too heavy to load on your light(?) client.  And as you mentioned, you
must also make it invisible.  

 If your applet does other things in your client scheme, I would _maybe_
say, go with the applet-based communication.  But I would not have the
applet just for communication with the server. 

IMHO, JavaScript approach works in 95% of these cases and can be slapped
together in just a couple of hours.  (Unless you visit these boards
frequently, of course!! :-))

Good luck!

Greg



-----Original Message-----
From: Roger Adema [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 2:38 PM
To: JDJList
Subject: [jdjlist] Pushing data to a browser


Hello, everyone -

I have a question that isn't strictly Java-related, but there seems to be a
lot of knowledgeable people that subscribe to this mailing list. so I'm
hoping someone can point me in the right direction.  I know I run the risk
of having several people point me in different directions, but I'm willing
to take that risk (having several alternatives to choose from is way better
than having no alternatives :-)).  I am pretty new to web application
programming in general, so I won't be surprised at all if this problem can
be solved in a standard, straightforward way - I just haven't stumbled onto
it yet.

I am trying to webify a legacy app and I need to solve the problem where
the application may need to send unsolicited data to the "display" (which
is actually represented by a browser).  The problem I'm running into is
that I need to push this data to the browser when it doesn't know it's
coming.  The best way I can think of solving this is to have an applet
running in an invisible frame that opens a socket to which a servlet on the
web server sends some sort of "refresh" notification when the unsolicited
data is available, and then have the applet use the Java-JavaScript
interface to cause the browser to ask for a refreshed web page.

Are there other, better approaches?  What are the gotcha's in the approach
outlined above?  Any help is much appreciated.

Regards,
Roger



To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm

To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm
To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm

To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm

[jdjlist] RE: Pushing data to a browser

Reply via email to