Client Programming Tutorial Notes

Last modified: Fri Apr 18 11:09:12 EDT

I. Moving Beyond Static HTML

Before the web, people used desktop applications to perform tasks. If the task involved access and retrieval of information from a remote machine it was called client-server, three-tiered architecture, or something similar. People still want to do that, but now they want to do it using the web; they want it to be easy, and they want it to be cheap. The trend of client-side web programming is to provide services which make a web browser act more like a familiar desktop application, and to provide services which are more like distributed computing.

Desktop applications commonly use a Graphical User Interface (GUI) which handles mouse events. They also use networking and local processing power. Web browsers are beginning to offer these capabilities as their use changes from the display of static pages to more active content. The original paradigm used in the web is that pages are displayed on the browser, but all processing occurs on the server. This does not scale well with a large number of clients, makes pages static and not very much like applications. Moving processing into the client makes it easier to write pages which respond to events, perform local validation, scale well with the number of clients, and reduce network load and round-trip delays. Client programming with the web offers the potential to offer the best of both desktop applications and the web.

There are a number of different approaches to client-side programming offering differing degrees of user interface richness, complexity, security, distributed computing power, and ease of installation and use. They may be grouped into categories based on functionality as follows:

1. Handle New Types of Information
   
   • Helper Applications
   • Plugins

2. Provide Local Processing
   
   • HTML 3.2 Client-Side Features (Client-Side Image Maps, Style Sheets)
   • Browser Scripts (e.g. JavaScript, VisualBasic)
   • Java Applets
   • LiveConnect
   • Dynamic HTML

3. Integrate with Objects or Applications
   • Spyglass Software Development Interface
   • ActiveX

II. Techniques For Client-Side Programming

1. Handle New Types of Information

Helper applications and plugins have many similarities. Both are compiled to run on a specific operating system and hardware platform. Both have full access to files, the network, and other operating system resources. Both must be installed by the user, which requires downloading the correct version from a known site (or installing from a CD-ROM or other media), installing in the correct location, and setting the appropriate browser options so that the helper or plugin is used.

The inherent security in this approach is minimal, and basically is the same as the security of an application. This requires trust of the vendor, which for something loaded over the network may not be that high. Once helper applications and plugins are signed using digital signatures, trust may be increased. Some plugins and helper applications may run hidden, with no visible window to the user, making trust even more important. Writing an application native to a machine is fairly complex, although the complexity depends greatly on the features required by the content type. The ability to write arbitrary code makes for very rich possibilities, using whatever features the machine provides, including the native windowing system. An example of a very useful content type which has both a helper application and plugin is the Adobe PDF format which allows page display.

a. Helper Applications

Once registered, when content of the specified type is received, the browser will call the helper application with a file, containing the content which was received from the server.

b. Plugins

A plugin is not an independent application, but is written to conform to a specific API. This API allows the browser to call methods in the plugin, and for the plugin to access information in the browser, about the browser and the current page. This is useful because plugins may share the browser display window with other page content when the plugin content.

Plugin content may be placed on an HTML page using the embed tag. This tag causes the browser to download the content, and reserves a portion of the browser window for that content:

The EMBED tag is not part of the HTML 3.2 specification, but is interpreted by Netscape 3.0 and Internet Explorer 3.0. It is similar to the IMG tag for images, but it supports the following additional attributes:

All attributes of the embed statement are passed to the plugin, so a plugin may also define additional attributes specific to itself for passing additional parameters.

2. Provide Local Processing

a. HTML 3.2 Client-Side Features

Cascading Style Sheets (CSS) are a proposed W3C standard which allow customizations of the presentation of HTML to be stored in a definition file, and used by documents which specify the style. Apart from the advantages of allowing control over presentation, and the ability to share style sheets, they permit style information to be loaded from the server once and then cached, improving performance if multiple documents share the same style.

b. Browser Scripts (e.g. JavaScript, VisualBasic)

Scripting is powerful because it can associate event handlers with Graphic User Interface elements created using HTML forms. Without event processing a form may either be submitted in its entirety to the server, or reset to the default state. With JavaScript, clicking on an element such as a button, or focusing on an element can cause a script to execute. This allows the page to be more interactive, and also provides a faster response time since the page is not submitted to the server when local processing is performed.

This also greatly reduces the complexity of processing a form, because the a server CGI script need not validate every field element if each field is validated locally. Simplifying server-side CGI processing is valuable, even if the page itself becomes more complicated. An advantage is that the script is located with the page, rather than CGI where it is in a different file which must be maintained consistently with the page.

The use of client-side scripting makes a page less portable, since the browser must support the language and the user must have it enabled in the browser to use it. One reason a user may have it disabled is because of possible security risks, both due to bugs in the browser scripting implementation, and because use of a script may cause security problems. JavaScript has had a history of security holes, which have been fixed as they are found. It is still possible to create simple denial of service attacks, such as disabling the user's back button.

Scripts are embedded in HTML with the script tag:

<SCRIPT LANGUAGE="JavaScript"> scripting language elements </SCRIPT>

HTML tags may have script elements associated with them. Using JavaScript, HTML form buttons may have an onClick method associated with them, which causes the method to be called when the button is pressed:

<INPUT TYPE=BUTTON VALUE="Get Result"
onclick="getValue(form.x.value, form.y.value, form.result)">

The onclick attribute specifies the function to be called when the mouse button is pressed. Named elements of the HTML form (e.g. x, and y) may be accessed as shown.

JavaScript Example

For this example we define a form field which should contain a part number between 1 and 10, a function which checks the value, and a method which is called when the field is changed. The method definition follows:

<HTML>
<HEAD>
<title>JavaScript Validation Example</TITLE>

<SCRIPT LANGUAGE="JavaScript1.1">

function part_fail(msg, myform)
{
     alert(msg);
     myform.part.value = "";
     onChange="validate_part()";   	
     return false;
}

function validate_part()
{
   // access the form named "entryform" in this page
   var myform = document.entryform;

   // access the value of the "part" field in the "entry" form
   var number  = myform.part.value;

   // try to convert it to a number. 
   var value = parseInt(number, 10);

   // NaN: Not a number, always returns false on IE 3.0!
   if( isNaN(value) ) 
   {
	  return part_fail("Please enter a number 1 - 10.", myform);
   } 

   // make sure there was no trailing text or other conversion failure
   // (numeric value should be same as what was entered.

   var str = value.toString(10);
   if(str != number) {
	return part_fail("Please enter a number 1 - 10.", myform);
   }
   
   if((value < 1) || (value > 10)) 
   {
	return part_fail("Part numbers must be in range 1 - 10.", myform);
   }

   alert(value + " is ok.");
   onChange="validate_part()";   
   return true;
}

function checkForm()
{
   alert("Submit is disabled.");
   onSubmit="check_form()";   
   return false;
}

</SCRIPT>
</HEAD>

<BODY>
<CENTER>
<H1>JavaScript Validation Example</H1>

<FORM ACTION="doit.pl" NAME="entryform"
onSubmit="return checkForm()">
<TABLE>
<TR><TD>Part Number:</font></TD>
<TD> <INPUT TYPE=text NAME="part" SIZE=2 onChange="validate_part()"></TD></TR>
<TR><TD>Reason:</TD>
<TD><INPUT TYPE=text NAME="reason" SIZE=20></TD></TR>
</TABLE>
<P>
<INPUT TYPE=submit>
</FORM>
</CENTER>
<P>
This JavaScript only works with Netscape 3.0 and does not work with 
Internet Explorer 3.0 due to differences in JavaScript implementations.
<P>
This demo shows validation of the part field upon entry
(must be number 1-10).
<HR COLOR=purple>
</BODY>
</HTML>

c. Java Applets

Java Applets are instances of a Java class derived from the Applet class, which run in browsers, and are constrained to reduce security concerns. Java Applets are unable to use the native operating system calls directly, may not use native (e.g. C) methods, may not access the file system, and may only open network connections to the machine from which they came. Applets offer much of the power of application programs, without any need for installation on the users part, and without any of the security risks. Although Applets on a page may interact with each other, it is not possible to have them interact directly with other programs on the local machine.

Like images or embedded plugins, applets are allowed to use a portion of the browser window:

<APPLET CODE="MyApplet.class" WIDTH=200 HEIGHT=100>
<PARAM NAME=color VALUE="BLUE">
<PARAM NAME=reason VALUE="because">
This text only appears for a browser which is not Java capable (or has Java turned off).
</APPLET>

The applet tag is part of the HTML 3.2 specification. Applets are allowed to call the public methods of other applets on the same page, if they know their name.

Examples

This may be extended with applets which communicate back to a server, allowing a "chat" room to be created.

d. LiveConnect

A simple example is that of an HTML form which is used to control a Java Applet on the page, and which also contains a field which is updated by the applet. This approach allows the creation of a simple HTML interface for control of an applet which provides graphics unavailable in HTML.

The HTML page which displays the applet is:

<HTML>
<HEAD>
<TITLE>Form, JavaScript, Java Example</TITLE>

<SCRIPT LANGUAGE="JavaScript">
	 
	 function set_level()
	 {
	     var value = document.levelForm.Level.value;
 	     var i = parseInt(value, 10);

	     if( isNaN(i) || i < 0 || i > 100) {
	         alert("Level must be between 0 and 100 (these are interpreted as percent)");
	         document.levelForm.Level.value = document.LevelApplet.getlevel();
	     } else {
	        document.LevelApplet.setlevel(i);
     	}
	 
	     return false;
	 }
</SCRIPT>
</HEAD>
<BODY>

<TABLE WIDTH="50%">
<TR><TD ALIGN=LEFT>
<FORM ACTION="http://www.nowhere.bad/" NAME="levelForm">
<INPUT TYPE=text NAME=Level VALUE=25 SIZE=2>
<INPUT TYPE=button VALUE="Set Level"  onClick="set_level()">
</FORM>

</TD><TD ALIGN=LEFT>
<APPLET NAME="LevelApplet" CODE="LevelApplet.class"a width=50 height=100>
<PARAM NAME=color VALUE=blue>
<PARAM NAME=level VALUE=25>
</applet>
</TD></TR>
</TABLE>
<P>
This example demonstrates JavaScript being used to send form contents to
an Java applet, and a Java applet using JavaScript to send values to a form.
<HR>
</BODY>
</HTML>

The applet source itself is:

import java.util.*;
import java.applet.*;
import java.awt.*;

public class LevelApplet extends Applet {
    
  public void init() {
    String w = getParameter("width");

    if(w != null) {
      width = Integer.parseInt(w);
    }

    String h = getParameter("height");

    if(h != null) {
      height = Integer.parseInt(h);
    }

    _color_map = new ColorMap();
    String color = getParameter("color");    
    _the_color = _color_map.getColorParameter(color, Color.blue);	    

    String level_str = getParameter("level");    
    if(level_str != null) {
      _level = Integer.parseInt(level_str);
    }

  }

  public void paint(Graphics g) {

    g.setColor(_the_color);
    g.drawRect(0, 0, width - 1 , height - 1);

    float _factor = (100 - _level)/100;

    int yval = (int) (_factor * height);
    int ywidth = (int) (_level * height/100);

    g.fillRect(0 , yval, width, ywidth);
  }

  public void setlevel(int level) {
      _level = level;
      repaint(0, 0, width, height);
  }

  public int getlevel() {
   return (int) _level;
  }

  int width = 200;
  int height= 300;
  ColorMap _color_map;
  Color _the_color;

  float _level = 100;
}

e. Dynamic HTML

Dynamic HTML allows greater dynamic interaction, including the ability to change the size or font properties of text dynamically, the ability to show or hide elements, and the ability to position elements on the page (using a proposed extension of CSS). The ability to position elements allows precise control over presentation, at the cost of portability issues:

In addition to positioning, dynamic html allows elements to be layered in front or in back of each other. Combined with JavaScript, this provides for opportunities in animation, such as having fish move in front and behind of pillars.

There is also a new Netscape plugin API (4.0) which allows plugins to be transparent and integrated with HTML rendering.

3. Integrate with Objects or Applications

a. Peer-to-Peer Client APIs

The Spyglass Software Development Interface (SDI) is a specification which defines how an application may register with a browser to receive event notifications, as well as to send events to the browser to request that it perform actions. On Windows NT, DDE and OLE are used to to provide this interface to the Netscape browser. On Unix, Mosaic supports CCI, but Netscape does not (it does not support sending events to the application). On the Mac, AppleEvents may be used with Netscape.

A useful example of this interface is when an application registers with the browser to receive notification of each URL requested by the browser, as well as a copy of each page received by the browser. This allows the application to observe browsing activity and act upon it. The ability to request the browser to load pages allows an application to control the browser.

This approach shares the disadvantages of helper applications, in that it requires a user to trust and install a machine-dependent application on their machine. It also only works with specific browsers, and the protocol robustness is dependent on the browser implementation. The primary advantage is that it provides more integration than a helper application, and was available in early browsers.

b. ActiveX

III. Selected References