Section 10.6. Working with Browsers and the Java Plugin

10.6 Working with Browsers and the Java Plugin

If you have attempted to use any of the ColdFusion <CFFORM> controls or participate on a ColdFusion news list, you have likely encountered some difficulty. Often, the controls will not display or users will receive an error message regarding the browser's inability to find the necessary files. In some cases, the applet will appear to load, but it will never quite load; however, upon viewing the source of the .cfm page, you can find that all of the code for the applet and its accompanying data (as in the case of <cfgrid> ) has been sent to the client.

In order to use any of the Java form controls, the user is required to download the Java plugin software. This is a 5 MB download that only needs to be downloaded once, but it can be confusing for users. So, consider the connection speed your users are likely to have if you are thinking of deploying an app with one of these controls. These form controls are sometimes considered too unreliable to use in a public environment, and their use has commonly been restricted to intranets , where browsers and downloads can be controlled to an extent.

For ColdFusion 5, these controls were bundled in a single .jar file. Prior to that, the control applets were downloaded differently. As you may recall, the ENABLECAB attribute of these form controls allowed all of the Java classes that the controls required to be loaded by a Microsoft Internet Explorer .cab file (cabinet files are the Microsoft equivalent of a .jar file). This meant that you could view the applets rather more quickly in Internet Explorer than in Netscape. That attribute is now deprecated, because all browsers will use the .jar .

The reason that working with these controls can be difficult is not due to any error in craftsmanship. The controls, and Java applets in general, are victims of the browser wars. Increased interest in server-side Java, which we cover shortly, was also accompanied by a decrease in interest in using applets. Here is an outline of some of the difficulties:

The Java support that is built into browsers such as Internet Explorer and Netscape Navigator is based on JDK 1.1. If you use functionality in your applets such as Swing classes or the regular expression API, your end users won't have these installed on their systems in most cases. The workaround here is to have the Swing .jar downloaded with your applet.
The Java plugin, which ColdFusion uses, will replace the Virtual Machine that comes in the browsers with one by Sun (JavaSoft). Again, if your users have not downloaded this plugin before, they will have to endure a 5 MB download before your program starts downloading.

The second most reliable thing to do is insist that your users download the plugin, and give them rather detailed instructions on what they need to do to make sure that it works, and what to do in case they cannot view your applet. The most reliable thing to do is to avoid using applets at all, except in an intranet environment where your sys admin can control the capabilities of each user's browser.

10.6.1 Passing Parameters into Applets

You can pass parameters defined on your HTML page into applets using the <param> tag. They take this form:

 <param name="somestring" value="thevalue">

These tags must be nested inside the <applet> opening and closing tags. Then, inside the applet code, you access the value of the parameter using getParameter() with the name as the argument. It returns a string if there is a parameter with the given name, but it returns null otherwise . Usage is like this:

 String s = getParameter("Username");

Here is an example program that displays values passed into an applet from parameters.

10.6.2 `ParamApplet.java`

 /**   * <p>Title: ParamApplet</p>  * <p>Description: Outputs parameters passed to the applet  *  inside an oval.</p>  *  * @author E Hewitt  * @version 1.0  */ import java.applet.Applet; import java.awt.*; public class ParamApplet extends Applet { public void init() {        setBackground(Color.white); }     public void paint(Graphics g) {       String s = getParameter("name");       String sD = getParameter("number");       String message = "Hello, " + s + ". Your number is: " + sD;       g.drawOval(20,20,250,100);       g.drawString(message, 60, 70);     } }

Remember that when using appletviewer (or a browser, for that matter), you must call the HTML page that displays the applet directly. This can be hard to remember when we've just gotten used to running Java programs by calling them directly. Here's an accompanying HTML page:

10.6.3 `ShowParamApplet.html`

 <html>  <head> <title>ParamApplet Test</title> </head> <body> <applet align="center" code="ParamApplet.class"     width="300" height="300">     <param name = "name" value="Eben">     <param name = "number" value="3.14"> </applet> </body> </html>

The output is shown in Figure 10.6.

Figure 10.6. Displaying values passed into an applet from an HTML page.

graphics/10fig06.gif

10.6.4 Setting Applet Parameters Dynamically in ColdFusion

You can set parameters that you pass to Java applets, just as you might hope. Let's replace our static HTML page with a ColdFusion page that sets CF variables to pass into the applet. The applet code itself need not change.

10.6.5 `ShowParamApplet.cfm`

 <html>  <head> <title>ParamApplet Test</title> </head> <body> <cfset name = "Fabio"> <cfset number = 9.9> <applet align="center" code="ParamApplet.class" width="300" height="300"> <param name = "name" value="<cfoutput>#name#</cfoutput>"> <param name = "number" value="<cfoutput>#number#</cfoutput>"> </applet> </body> </html>

The output of loading the CFM page in Netscape 6 is shown in Figure 10.7.

Figure 10.7. Sending ColdFusion parameters into an applet and outputting them.

graphics/10fig07.gif

10.6.6 Applets, Java Applications, and WebStart

Note that a chief difference between applets and regular Java programs is that they do not have access to the local file system. This is the only way that applets could be distributed with any manner of security. Applets operate in their own little sandbox so that they can be trusted. While it is certainly not impossible , it is difficult to write and distribute a virus in Java because of the security measures that are built into the language. But it means that there are certain things we cannot do. For instance, much to my dismay, I cannot execute a method that captures my drawing from the DrawingApplet and saves it to a file. I could write that method ”the applet would compile; it just would refuse on the basis of its inability to access local system resources. That is a major difference between applets and applications.

In the last two years there has been a very interesting development that takes the notion of applets one big step further. This development, which we examine later in this book, is called Java WebStart. WebStart allows you to distribute full-blown programs from the Web and execute them on the local machine. With the user's permission, you can gain access to system files, printers, and the network. Java WebStart requires surprisingly little configuration on the server to get up and running.

Top