WEB PROGRAMMING

APPENDIX

WEB PROGRAMMING The Web was originally designed to deliver static Web pages from a Web server connected somewhere on the Internet to a Web browser sitting on a user’s desktop computer. Basically, all a user could do was click on a hot spot or hypertext link to retrieve a new page, read it, and then go on to the next page. The Web was not designed to support EC sites, especially B2C sites. In its original state, it was not possible to create pages that would allow consumers to easily determine what products were for sale, to select products as they moved from page to page (i.e., an electronic shopping cart), to place an order, or to verify an order. Similarly, there was no simple way to integrate a Web server with a database system containing product, pricing, and promotional data with transactional systems for processing orders and with payment systems for handling credit card purchases and settlements. Over time, these limitations have been addressed. First, forms were added to HTML. Forms provided a way to produce Web pages from which a consumer could select, order, and pay for products. Second, special programming and scripting languages (e.g., Java and JavaScript) were created. These newer languages allowed application developers to produce interactive Web pages whose functionality emulated the rich functionality of standard Windows-based applications. Finally, a standard application programming interface (API), called the common gateway interface (CGI), was introduced. Generally speaking, an API provides a way for one software program to communicate with another, whereas CGI provides a way for software developers and application programmers to integrate Web servers with various back-end programs and data sources. Because of CGI’s inefficiencies, newer APIs and special database gateway programs were also introduced. As a result of these changes, the Web is now well suited for the dynamic world of EC. This appendix examines issues of end-user interactivity and dynamic data access. The first sections focus on Java and JavaScript, which are special programming languages that can be used to create Web pages with rich graphical user interfaces (GUIs). The remaining sections examine various methods—CGI programming, specialized APIs, and server-side scripting—for integrating a Web server with back-end programs, including relational databases.

DESKTOP INTERACTIVITY AND PROCESSING Most of us are familiar with various applications running on Microsoft Windows. One of the hallmarks of a Windows application is its GUI (i.e., its look and feel) and the on-screen interactivity it provides. To regular Windows users, scrolling, clicking, double-clicking, dragging and dropping, entering data, and similar actions are almost second nature. In Windows, the desktop computer on which the application resides handles these actions. For instance, if a user of Microsoft Excel enters a formula and hits the “Enter” key, then the desktop computer calculates the result, which is displayed immediately in the Excel spreadsheet. Even with a

C

application programming interface (API) A standard that provides a way for one software program to communicate with another. common gateway interface (CGI) A standard that provides a way for software developers and application programmers to integrate Web servers with various back-end programs and data sources.

C-2

Appendix C

client/server application where processing is distributed between a desktop computer and a back-end server, the desktop still handles the user’s actions. Initially, the type of interactivity found in a Windows application was missing from the Web. The earliest Web pages were built solely with HTML (described in detail in Appendix B). Until forms were added to HTML, the only action supported by HTML was the clicking on a hypertext link to access a new page. Forms added data entry capabilities and a series of new elements (e.g., radio buttons, check boxes, and dropdown selection lists). However, even with these new features, the only thing a user could do was click. In the same vein, there was no way for the browser (i.e., the user’s desktop) to process the user’s actions. All the processing had to occur on a Web server. Although this is enough interactivity for some applications, many applications are better served by the types of interactions supported by Windows. This is where Java and scripting languages such as JavaScript come into play. Java and JavaScript provide the means to create applications that support the types of user interactions found in Windows. They also make it possible for processing to be distributed between the desktop and the server.

JAVA

virtual machine (VM) A run-time environment in Java that enables any computer to run a Java program; all Web browsers have built-in Java VMs.

Java’s roots are in work done at the beginning of the 1990s by a developer named James Gosling at Sun Microsystems. This original work focused on developing software and networks for consumer devices (such as VCRs, PDAs, toasters, and so forth). The result of this work was a programming language called Oak. Recognizing the growing importance of the Internet, the developers at Sun Microsystems turned their attention from consumer devices to making Oak a premier programming language for the Web. In 1995, Oak was renamed Java. In that same year, a number of software and hardware vendors licensed Java from Sun, including IBM, Netscape, Microsoft, and Symantec. Today, it is estimated that there are over 1 million programmers using Java to develop Web and network-based applications. Java is similar to C and can be used to produce stand-alone applications or applets. An applet is a Java program that is written for and runs in a Web browser. As a programming language, Java is well suited to Web development because of its native support for Internet communications. If Java was simply a programming language, then it would not have generated much interest outside the programming community. After all, how many of us are excited or know much about C, even though it is the development language used in most commercial software products? What makes Java interesting to industry observers is that it also has a run-time environment called a virtual machine (VM). Any computer that has a Java VM can run a Java program. All Web browsers have built-in Java VMs, although in the future users of the Microsoft browser (Internet Explorer 6.0) will have to download a Java VM to their desktops. Java differs from other programming language in one important respect. Other programming languages require developers to write and then compile their programs on the machine on which the program is to be run. Compilation refers to the process of converting the human readable form of a program into binary or machine code that can be run by a specific computer. For example, if a developer wants a program to run on a PC and a Unix computer, then the developer must

Appendix C

write and compile the program on both machines. Even with the same type of computer (e.g., a PC), the program must be written for and compiled on each generation of the machine or the machine’s operating system (e.g., Windows 98 versus Windows 2000). Of course, you can see that standard program languages are ill suited for the Web because of the large variety of computers that are attached to it. In contrast, Java is a “write once, run anywhere” (WORA) programming language. That is, a programmer writes a Java program and compiles it. Unlike other language compilers that turn a program into machine-specific code, the Java compiler produces an intermediate form of code (called byte code) that is not specific to a particular machine. When Java byte code is sent to a Web browser, the Java VM executes it on the fly. Where does the Java VM reside? It comes with the Web browser. Special tags are used to incorporate applets within an HTML page. Exhibit C.1 shows a Java-based spreadsheet and chart that might be used to analyze sales data for online beverage, food, and nonconsumable purchases. This particular page has two Java applets—a grid and a chart. Both of these applets allow the end user to navigate through the data, selecting different slices of data, and to drill down into underlying detail. Although the data might be displayed in a static HTML table and image (a .jpg or .gif file), a static table or image could not provide end users with the same interactive capabilities. The code behind part of this page is shown in Exhibit C.2. The applets are defined by the . . .

EXHIBIT C.1

Java Spreadsheet from Comshare Decision

Source: Comshare Decision, 2002.

C-3

C-4

Appendix C

tags. With each of these applets, the “CODE” parameter indicates the Java code to be downloaded from the Web server. The WIDTH and HEIGHT parameters of the tags define rectangular regions for displaying the applets on the Web page. When a Web browser accesses a page with an tag, it begins by rendering the page. During this process, it sees the tag and knows to (1) reserve a display space within the page and (2) request the Web server to send the Java applet code. Once the applet arrives, the browser’s Java VM begins executing the applet code. The Java VM handles any interaction that takes place between the user and an applet. It is as if there is a separate program running within the page. One advantage of having the Java VM in control is that it can enforce security, providing a “sandbox” that limits the applet’s access to system resources. For the most part, applets do not have access to any system resources. For instance, applets cannot read from or write to files on the end user’s computer. This is why it is difficult for a hacker to write an applet that plays havoc with a user’s system. However, there are drawbacks to this restriction. The fact that an applet cannot read or write to disk means that an end user cannot store interim work or the results of any analysis. This sort of functionality is crucial for those users (e.g., mobile executives) who do not have constant access to the Web server. In spite of its power, few EC applications use Java applets. Most applications still rely on Web forms and client-side scripting (see discussion later in appendix) to provide end-user interactivity. However, Java is used quite extensively for

EXHIBIT C.2

Java Applet Tags for Spreadsheet in Exhibit C.1

DecisionWeb

Appendix C

C-5

server-side processing in the form of Java beans and Java servlets. Over the past year, Microsoft has introduced a Java competitor called C# (i.e., “C sharp”). Unlike Java, C# runs only on computers with a Microsoft operating system (i.e., Windows XP, Windows 2000, etc.).

JAVASCRIPT AND THE DOCUMENT OBJECT MODEL Java applets are not the only way to add interactivity to Web pages. Interactivity can also be provided through client-side scripting using a language such as JavaScript. JavaScript, often confused with Java, is not a lightweight version of Java. The two languages have different capabilities and are used for different purposes. JavaScript is used to control the objects, content, and interactions within a Web page. Unlike Java, JavaScript cannot be used to produce stand-alone applications. To program in JavaScript, you simply write the JavaScript programming statements and functions directly in the Web page, interspersed with the HTML statements. When a Web browser receives a Web page containing JavaScript, it automatically knows to execute the program. Exhibit C.3 shows how JavaScript is embedded among the HTML statements on a Web page. The page shown in Exhibit C.4 is what results when the code is executed. In Exhibit C.3, the JavaScript program is contained between the . . . tags. Without going into the details, when the user clicks the SUBMIT button, the function “onClick” is executed. The function checks to see if the value of the “Name” input field in this particular form is empty.

EXHIBIT C.3

JavaScript Validating User Input

E-Commerce FUNCTION valcheck(){ if (document.forms[0].elements[0].value  ““){ alert(“Please enter a name”); } }

Javascript Validation