Before Active Server Pages came along, there were Web browsers that could interpret script code embedded in the HTML, and host Java or ActiveX components. ASP is a very powerful environment that enables quick and easy creation of a huge variety of Web pages. However, there are times when the fact that ASP can only execute script and use objects on the Web server creates limitations, such as we've discovered with client/server applications. Quite often, these limitations can be overcome by using client-side code and a range of special objects, in tandem with pages generated by ASP.
In the next two chapters, we'll be covering the ways that we can program the client in detail. As just a simple example of the power this provides, think back to the task of performing validation of data entered on a form like our earlier logon code. If the user is supposed to supply a six character user name, and they enter only four characters, verification is bound to fail—but it still involves a trip across the network to the Web server, and back again, just to inform them that they didn't enter enough characters. Client-side code can do this validation, and inform the user of their mistake, before the form is actually submitted to the server.
But we know that it's generally much easier to perform complicated computations and tasks on the server and send back a completed page consisting of solely HTML, than it is to send a page and attempt to perform many of the same tasks via HTTP (especially with today’s technology). And since we know the kind of browser our page will be viewed on, we can modify our page so that it suits that browser well. So there are two sides to the argument.
To decide how you split the processing in your applications, keep in mind the different layers of the client/server model, and the arguments for and against client-side programming in your particular environment. We saw earlier that the business rules should exist on the client-side where possible, and the length of an acceptable user name is a valid business rule. However, as we've seen earlier, actually processing the user name is a server-side job—to maintain security, concurrency and efficiency.
There are also the concerns of browser compatibility. However, next-generation browsers like Internet Explorer and Netscape Navigator have capabilities that are reasonably standardized, and make client-side interactivity a reality. For example:
Need to display data in a format more robust and interactive than allowed by HTML? Just add an object to your page and let it do the work.
Need to provide immediate feedback to someone entering text on a form without requiring that they send another request to your server? Use client-side code to validate their input.
Want to show some snazzy animation or graphic, but don’t know how to do it in HTML? Insert a Java applet or ActiveX control and control it with code in the web page.
The MSN Investor page at
shows an excellent example of how client- and server-side code can be combined to produce a really interactive Web page. It uses an ActiveX control to track your portfolio and provide current information on stocks.http://investor.msn.com
Based on all we've seen up to now, you might be wondering exactly how we can accomplish these wonderful new tricks. How does the browser know what to execute as script code? How exactly does the script code interact with the browser, and with objects on the page? How do objects get from the server to the client in the first place? These are the subjects we’ll be talking about for much of the next chapter, and we'll be putting the techniques to use with ASP in the rest of this book.
Fortunately, there are a lot of similarities between client-side and server-side scripting, and experience working with Active Server Pages code makes it easy to pick up the new topics that we'll be introducing. In many cases, the script language you’re using with ASP at the moment can be used inside a browser. And because you’re used to using objects with ASP, you won’t have to learn a completely new way to use objects within HTML.
The major change is the platform or computer system our code will be running on. If we’re using ASP, we know a lot about our system: it has certain software packages (like database management systems) installed, it’s running a Microsoft operating system, and so on. In other words, it’s a relatively constant environment that we have some measure of control over. The client system is a completely different ballgame.
People viewing our pages may be doing so from a variety of operating systems, with many different browsers, and with different software installed. If you’ve used the Browser Capabilities component we introduced in Chapter 3, you’ve had some experience with the differences in browsers. Some support Java applets, others support Java applets and ActiveX controls, and others support no objects at all.
The same thing occurs for scripting languages: the browser may be able to interpret VBScript and/or JavaScript, or it might not know what a script actually is at all. In fact, our pages may even experience browsers who understand different dialects of these languages. For example, the version of JavaScript in Navigator 3.0 differs from both the versions in Internet Explorer and Navigator 2.0. With ASP, we’ve been using VBScript version 2.0, but many of our Internet Explorer users may only have version 1.0. While the difference between these languages is often minor, it illustrates how different browsers can be, and how this must be a consideration when we design pages with client-side functionality.
In fact, it's a bit like writing a program in Fortran and then giving it to someone else, who may know nothing about programming, to compile. And just for fun, not telling them what language it actually is, but letting them see what happens with the compiler they use for all their other daily jobs.
Another important difference in platforms is the software that is installed or available on each system. We know that we can always use the Browser Capabilities component when writing ASP code, because we know that it's installed on our server. When we use objects in our HTML pages, we don’t have any sort of assurance that this is the case. Just because I have a cool ActiveX control on my machine doesn’t mean that you do too. We need to make sure that the code gets sent to the client machine so that it can be executed.
Both browsers that support objects, Navigator and Internet Explorer, have mechanisms to make sure that this happens, and we’ll cover this in Chapter 8. Of course, if you are developing for the corporate Intranet, you can control your whole environment. Selecting the correct browser software solves the problem as far as both the scripting language and object support are concerned. And you can also more closely control what software is installed on each client.
If you’re an old client-side scripting master—as if those really exist in a field as new as this one—you might want to skip ahead to the 'examples' section of Chapter 8. These hands-on examples show the code you’d need to write to perform some common tasks that aren’t possible with just ASP, as well as showing how ASP can be used to enhance previous client-side only web pages.
Before we dive into our client-side excursion, we'll finish up this chapter with a look at some of the object terminology you'll be seeing throughout the rest of the book. This will also help you to understand some of the pressures that Web developers are under when designing applications that use client-side objects. Again, on the corporate Intranet, you can control your environment and make more free choices about the technologies you decide to run with.
The two most common external objects used in client-side programming today are Java Applets and ActiveX Controls. Both of these technologies provide the same end-result: a portion of the page dedicated to whatever visual representation the object provides for itself, and a portion of the browser’s processing time for whatever computations the object needs to execute. Objects can range from a simple button to a complete word-processor or spreadsheet in a window.
Web browsers first supported applets. Created with the Java programming language (similar to C++), these small lumps of code run on any system that can interpret the ‘bytecodes’ that a Java compiler produces. Because Java-enabled Web browsers run on Windows, Macintosh, and Unix operating systems, Java applets can be viewed on any of these platforms. Although some vendors are developing full-blown applications with Java, the primary use of the language today is in creating applets that only run inside Web pages.
Currently Java applets don’t have any standard way to communicate between each other, though Sun has proposed a standard called Java Beans that achieves this. Microsoft already supports applet interaction through the same component object model (COM) that it uses for communication between ActiveX controls and other OLE/COM components. Java applets in today’s Web browsers run inside of a ‘sandbox’, which limits their functionality to operations that can’t hurt the computer they’re running on. Both Netscape Navigator and Internet Explorer support Java applets, although their methods of connecting script code to applets differ greatly.
Browsers that can host ActiveX controls provide an alternative way to add objects to a Web page. ActiveX controls are components that can plug into any ActiveX control host. Controls have been around for a long time and there are literally thousands of pre-written ones implementing every function under the sun available for purchase or download. In addition to Internet Explorer and the next version of Navigator, a wide range of other applications, including Visual Basic, all Office 97 applications, Visual C++, and Visual J++ can also use these ActiveX controls.
While Java applets are platform independent, ActiveX controls are language independent—they can be created with a wide variety of languages, including C, C++, Java, and Visual Basic. Microsoft has announced their intention to support ActiveX controls on other platforms. Currently, controls only run on Windows operating systems, though COM has been ported to both the Mac OS and Solaris, and we will soon be able to create controls for use on these operating systems.
ActiveX controls in a web page have full access to the computer and can control all of its parts. This is useful because it doesn’t limit developers in what they can do with a control although, without proper safety measures, a malicious control could possibly harm the computer it's running on. Controls achieve safety through a method known as code signing. We’ll cover this topic in more detail in the following chapters, when we talk about security and code download.
So what does all this mean for us? If we're creating a page with an object that needs to be viewable on many platforms, Java is the way to go. If we're developing with Windows and our clients are going to be running a Windows operating system, we might want to use an ActiveX control (or group of controls) instead. This way we can take advantage of the huge base of previously written controls, and the easy development of custom controls offered by Visual Basic 5.0.