Top 10 in 2008
5 popular archives:
All selections are based on page views.
JW hot topic: Tech careers in a slump
Seems like new layoffs are announced every week, projects are dying and software developers are feeling the IT budget squeeze.
Being nervous isn't a crime, but you're better off with information, advice, and a plan.
From the IDG News Network:
Page 2 of 6
Each of the above solutions has its advantages and disadvantages in complexity, security, performance, scalability, browser Java compatibility, and restrictions such as firewalls. The optimal solution strongly depends on the requirements of your application. For example, when users require a direct interaction with the state, such as in a shared whiteboard, server-side callbacks or messaging can be a powerful technique.
But we are still working within the confines of a browser. Unless the applet constitutes the entire client application, it
is difficult to integrate the HTML content with the updates coming from the server. Considering this, how can we alter the
content from within the applet when it gets the callback or message? A frequent solution is to refresh the page by calling
AppletContext.showDocument(URL) within the callback method. This instructs the browser to change the page with the new URL.
Since HTML is a powerful layout language, wouldn't it be nice to be able directly to alter parts of the HTML content with incremental data coming from the server? This would be an ideal scheme for Web applications where content on the server changes dynamically and the required user-to-server interaction -- for example, that driven by HTML forms.
The pushlet mechanism I developed is lightweight and thin on the client; it requires no applets or plug-ins, directly integrates with scripting and HTML, and uses standard HTTP connections; and it can be deployed (in theory!) in any Java-servlet server. It is certainly not meant to replace the traditional solutions outlined above. On the contrary, pushlets may be another option in your toolbox. As a Java architect or developer, you can determine the trade-offs and choose what is best for your particular application.
So what are a pushlet and how does it work? In its basic form a pushlet is extremely simple. I will show the basics through a few examples. It's also time to see some code!
Pushlets are based on HTTP streaming, a technique sometimes used in multimedia viewing applications such as QuickTime or RealAudio. Instead of closing the HTTP connection after fetching an HTML page, the connection remains open while fresh data is pushed to the client.
Taking the idea of HTTP streaming, we could develop a JSP or servlet that continuously sends new HTML content back to the client in a timer loop, as seen in the example below:
<HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> </HEAD> <BODY BGCOLOR="blue" TEXT="white"> <% int i = 1;
try { while (true) { out.print("<h1>"+(i++)+"</h1>"); out.flush();
try { Thread.sleep(3000); } catch (InterruptedException e) { out.print("<h1>"+e+"</h1>"); } } } catch (Exception e) { out.print("<h1>"+e+"</h1>"); } %> </BODY> </HTML>
To see this example in action, from the Pushlets page, click on Examples, then Basics. Then click Run from the HTML Push section. The above example is not terribly useful, since the pushed content is continuously appended to the page while our intention was to alter the loaded content (that is, to show only the actual value of the counter).