Netscape ONE is a technology for developing Web applications-with everything that implies. The content of the Web is gradually shifting from conventional sites, with their emphasis on static files of HTML, to applications that mix dynamic content and multimedia with static pages.
This chapter provides a tour of the Netscape ONE application technology, with an emphasis on LiveWire, Netscape's application development environment. The chapter shows how to use LiveWire's features to build a simple Web application. The application contains static content, Java, JavaScript, and plug-ins. Along the way, this chapter shows how to use LiveWire to build and install the application with little or no programming.
High-energy physicists and other technically-oriented people used the original World Wide Web as a way to keep their particular academic community aware of their progress. The primary vehicle for packaging information was a static file with lines in the HyperText Markup Language (HTML). Developers used simple tools, such as text editors, to assemble information. The fact that some of these tools require the user to learn an arcane series of commands did not bother these early Webmasters-they used tools like the vi and emacs editors, FTP, and e-mail on a daily basis.
As the Web takes its place as a major medium for news, education, and product information, the population of users and Webmasters continues to move away from the academic and technical community. Many of the people developing and maintaining Web sites today have non-technical backgrounds-in graphic arts and advertising, for example. These people are more comfortable with a graphical environment such as Microsoft Windows or the Macintosh.
This section describes how Web sites are structured, built, and maintained in a pre-LiveWire environment.
The core of a conventional Web site is a set of files, each of which contains one "page" of content. The content and structure of the page are defined with HTML. HTML consists of a series of simple free-form ASCII statements-there are no special binary codes or formatting to worry about. As a result, many site developers produce these pages with a basic text editor or a word processor (with files saved in text-only format). Graphics are incorporated by name. If the developer does not work directly on the machine that hosts the Web server, he or she uses a tool like FTP to move the graphics file to the server.
Figure 2.1 shows a simple static page. Listing 2.1 contains the HTML that produces this page.
Figure 2.1: Most pages on the Web are generated from static HTML files.
Listing 2.1 -The HTML for Figure 2.1
<HTML> <HEAD> <TITLE>Sample Page</TITLE> </HEAD> <BODY> <P> This page is a very simple example of HTML. It contains a HEAD section, which contains information <EM>about</EM> the page, and a BODY section, which contains the content of the page. </P> <P> HTML documents can contain text, graphics, and links. Here's a link that takes the visitor to <A HREF="http://www.whitehouse.gov">the White House site</A>. </P> </BODY> </HTML>
While the division between static HTML and dynamic content is blurred in LiveWire applications, the blending of static content and dynamic content does not change the fact that the content is the key to success in a Web site. Chapter 3, "Standard HTML," and Chapter 4, "Netscape Enhancements to HTML," contain information about making the site effective through high-quality content.
To understand why LiveWire and its component, Netscape Navigator Gold, simplify static page development, consider how pages were developed on conventional sites.
An HTML page is generated from a file of HTML tags. Each tag may take attributes. Content is interwoven with the tags. For example, to put up a list of three items, the HTML writer can say:
<UL> <LI>This list is embedded between a "begin list" tag and an "end list" tag. <LI>Each list item starts with an LI tag. <LI>The UL stands for "unnumbered list" and refers to the fact that each element is marked with a bullet rather than a number. </UL>
Let's use Netscape Navigator Gold to build the same construct. Launch Navigator Gold and choose File, New Document, Blank.
The resulting screen should have three rows of toolbar buttons at the top, as shown in Figure 2.2. If it does not, pull down the Options menu and make sure that Show File/Edit Toolbar, Show Character Format Toolbar, and Show Paragraph Format Toolbar are all checked.
Figure 2.2: By default, the blank editor window in Netscape Navigator Gold has three toolbars.
Type or paste some lines of text into the window. Press Enter or Return (depending on your keyboard) at the end of each list item. Now select the text and click the Unordered List button on the Paragraph Format toolbar. Your results should be similar to the screen shown in Figure 2.3.
Figure 2.3: The Unordered List button transforms text into an unordered list.
When you use a tool like the Unordered List button, Netscape Navigator Gold does two things. First, it transforms the image on the screen, making Navigator Gold a WYSIWYG editor. Second, it causes Navigator Gold to generate the proper HTML when it saves the file.
Using conventional methods, the HTML writer uses coded tags and attributes with a conventional text editor. Using Netscape Navigator Gold, the writer selects text and applies attributes chosen from the toolbars.
Although, occasionally, one may need to go back into a page to
fine tune some of Navigator Gold's choices, Netscape Navigator
Gold can clearly reduce much of the labor associated with writing
Web pages.
| Tip |
If you prefer more working space and want to eliminate the toolbars, uncheck them where they appear under the Options menu. The functions are still available from the menus. For example, the unordered list is available at Format, Paragraph, List Item, LI. |
Many Webmasters prefer to build their site using two machines: one for development and one for the "live" site. Navigator Gold supports "one-button" publishing of each single page, but LiveWire goes one better. Using the LiveWire Site Manager, you can build and validate the pages of an entire site on the development machine and then deploy them with a single command.
Specifically, Site Manager lets you do three things with the site:
Figure 2.4 shows a typical Site Manager window. In this example the Webmaster is checking the external links of the entire site from a single screen.
Most Webmasters agree that the key to building effective sites
is to supply high-quality content. This section starts with the
assumption that you have such content and describes some mechanisms
available in Netscape Navigator and Netscape Navigator Gold to
display your content well. Chapter 3, "Standard
HTML," and Chapter 4, "Netscape
Enhancements to HTML," describe additional design issues
as they relate to various versions of HTML.
| ON THE WEB |
http://search.netscape.com/assist/net_sites/starter/samples/index .html Netscape Gold starts with templates for a variety of page styles. Visit the online collection at this site. These templates have been professionally prepared and are a good starting point for the design of a site. |
| Caution |
The procedures given with these templates are designed for use with Netscape Navigator Gold and will not work in other browsers. |
Start by looking through the categories. Find a page that seems to meet your expectations and tastes. For example, you can choose the Catering Service page in the Products/Services category. The Catering Service page is shown in Figure 2.5 and is online at http://search.netscape.com/assist/net_site/starter/samples/templates/cater.html.
Figure 2.5: To use Netscape's templates, start by visiting the master copy online.
After you find a template you like, choose Edit Document from the File menu. Netscape Navigator Gold copies the document from the remote server to your hard drive. Now use the program's editing tools to fill in the template.
Managing Fonts and Their Kin Remember that in Navigator, the developer can control the font color and size. HTML 3.2 gives the developer somewhat less control, with tags like <BIG> and <SMALL>. The end user has control of the choice of fonts, overall size, and the color scheme.
Design your pages so that they look good with the default settings that are available in most browsers. Don't bother to tell the user how to set their browser-most will ignore any instructions you give, and many will be unable to carry out instructions because of differences in their browser. Instead, use HTML for the purpose for which it was intended: as a markup language that enables the developer to show the structure of a document, rather than control the exact appearance of the page.
The appropriate tool for desktop publishing on the Web is Adobe's Portable Document Format, or PDF. Using Adobe Acrobat, the developer prints a document to a special file format (PDF) and serves that file on the Web. Acrobat bundles graphics, fonts, and everything else necessary to reproduce the document on all common platforms.
When a visitor comes to your site and downloads the PDF file,
the browser invokes the Adobe Acrobat Reader, which reproduces
the original page. Adobe makes Acrobat Reader software available
free from its Web site at http://www.adobe.com/acrobat/.
| Note |
The Acrobat Reader software is available as a helper application and as a Navigator plug-in. For more information on plug-ins, see Part IV, "Extending Navigator with Plug-Ins." |
The original Acrobat Reader was a helper application-the user had to download the entire PDF file before Acrobat could open it. This condition led many Webmasters to conclude that PDF was too slow for day-to-day use. The latest Acrobat technology uses a plug-in-as soon as the PDF document starts downloading, the Acrobat plug-in begins to show the document. The user can then allow the download to complete or decide to stop the download after he or she has seen enough.
Figure 2.6 shows an example of a PDF document being viewed with the Adobe PDF Reader plug-in.
Netscape and the Color Table The developer uses color in the following four ways on the page:
Regardless of the reason a color is on the page, each color on a graphical page needs to be rendered by the end user's video card. Although some users have monochrome screens or only a few colors, most desktop computers can render colors from a palette of 256 colors.
After the color palette is filled, additional colors are rendered by combining colors that are available in the palette. The quality of the various combination algorithms varies-in general, to prevent the end user from receiving some surprising results. You want to ensure that the page does not exceed 256 colors.
Recall that most Internet users are using some version of Netscape Navigator, so it makes sense to build pages that render well in that product. (On an intranet, of course, you have corporate control over the browser and can ensure that users use a version of Navigator that is appropriate for their platform.) The color model used in Navigator (as well as most other products that put color on a computer screen) is to express a color as a combination of red, green, and blue. The model is called RGB, after those three colors.
The amount of each color present is expressed by a number that ranges from 0 to 255. These numbers are commonly expressed in base 16 (hexadecimal) notation, in which 0 10 is 0 16, and 255 10 is FF 16. Thus, the available colors range from #000000 (no red, no green, and no blue) to #FFFFFF (full red, full green, and full blue). The code "#000000" gives black and "#FFFFFF" gives white. Intermediate colors like #00FF00 (pure green) are available.
The RGB model can express a theoretical maximum of 256¥256¥256 colors-over 16 million colors in all. But remember, "theoretically" is often a code word for "not really." The video display circuitry on most desktop computers can render only 256 colors, and most of those slots are pre-assigned by Navigator, according to the following formula: Each of the three positions (Red, Green, and Blue) is filled by a number chosen from the list 00, 33, 66, 99, CC, and FF. Netscape pre-selects 6¥6¥6, or 216 colors. If the developer chooses, say, #33FF66 for a background color, that color is rendered correctly. If the developer chooses #43FF66, that color is not likely to be available in the color table. Netscape attempts to produce the color either by dithering or by using the closest available color (depending on the user's choice). Either way, the effect may not be what the developer has in mind.
With 216 colors to choose from, you can easily find color combinations
for the background, text, and links that fit within the Netscape
color table. With a little work, most buttons and incidental graphics
can be made to fit as well. But color photographs are notorious
for using up the color palette. Try to limit the number of colors
per picture to 128 (7 bits) or even 64 (6 bits). This decrease
in the number of colors used often makes little difference to
the eye, but has a pronounced effect on the color table and download
time.
| ON THE WEB |
http://www.infohiway.com/faster/index.html The Bandwidth Conservation Society operates this site, which shows the effect of reducing the number of bits available for representing color. |
The previous section describes how to put static content into a Web site or LiveWire application. Static pages have been part of Web sites since the beginning of the Web. This section describes dynamic content-pages whose content varies depending on changing conditions.
The easiest way to vary a portion of an otherwise static page
is to use server-side includes (SSIs). SSIs are directives
to the Web server that are embedded in HTML comments. The server
is configured to examine the HTML document for such comments and
to respond accordingly. Table 2.1 shows a few of the common SSI
directives.
| Directive | Example | Effect |
| #echo | <!--#echo
var="LAST MODIFIED"--> | Outputs the contents of the named variables. Possible variables include DOCUMENT_NAME, DOCUMENT_URI, DATE_LOCAL, and DATE_GMT. |
| #config | <!--#config
timefmt="%D"--> | Sets the format used for output of some of the other SSIs. |
| #exec | <!--#exec cgi="
/cgi-bin/dse/ test.cgi"--> | Runs the indicated program as a CGI script and returns the results. |
| Caution |
SSIs in general and exec in particular have reputations for causing security holes. While SSIs can be set up so that they pose less of a threat, many system administrators restrict how they are used. Check with your local administrator for details at your site. |
The SSI with the most potential for serving dynamic content is
exec. Using exec,
the developer can have a program run every time the page is requested.
| ON THE WEB |
http://www.dse.com/nikka/Talent/Painting/5.McLauchlin.shtml The top graphic on some of the artists' pages at the Nikka site is put there by an exec SSI. Visit a page like this one and select Reload several times. Note that the image at the top of the page is randomly selected each time the page is loaded. |
| ON THE WEB |
http://www.worldwidemart.com/scripts/ssi_image.shtml The random image CGI script on the Nikka site was developed by Matt Wright, who operates Matt's Script Archive. Matt's Script Archive is available online at http://www.worldwidemart.com/scripts/. The server-side include version of the random image generator is on that site at http://www.worldwidemart.com/scripts/ssi_image.shtml. |
When a user requests an URL, the server usually returns the requested file. If the requested file is, in fact, a CGI script, returning the file is exactly the wrong thing to do. Figure 2.7 shows what happens if a CGI script is returned as a file.
Figure 2.7: If a CGI script is not recognized as CGI, the result is source code sent to the browser.
The Webmaster must configure the server so that URLs that point
to files in a certain directory (like cgi-bin) or files with a
special file extension (like .cgi)
are not interpreted as requests for documents, but as requests
that the named file be executed. Thus, http://www.your.server.com/cgi-bin/formmail.pl
is not a request for the contents of the file formmail.pl in the
cgi-bin directory but is a request that the Perl program named
formmail.pl be executed. The results of that program (specifically,
anything sent to Perl's STDOUT)
are sent to the browser.
| Note |
In most popular operating systems, programs have three files opened for them when those programs start: standard input (STDIN), standard output (STDOUT), and standard error (STDERR). If the program is a CGI script, STDOUT is sent back to the client's browser, and STDERR is sent to the server's error log. If the CGI script was invoked by using the method POST, the contents of the HTML form are placed on STDIN for use by the CGI script. |
For more information about configuring your Web server to run CGI scripts, see Chapter 22, "CGI Scripts and Server-Side Includes," of Running a Perfect Netscape Site (Que, 1996).
Many Webmasters are concerned that CGI scripts open a security hole on their servers. For this reason, some Webmasters do not allow users to place CGI scripts on the server without the script being reviewed by a trusted staff member. Although it is possible to write CGI scripts that resist attack, the precaution against unreviewed scripts is sound.
The tradeoff between security concerns and usability issues is called a security stance. Many sites, such as those associated with a large company and linked to a corporate intranet, have a stance that favors strong security over ease of use. Webmasters at other sites may determine that a machine has very little sensitive material on it and may choose to permit CGI scripts with very few restrictions.
JavaScript, described later in this chapter (and more fully in
Chapter 5, "Client-Side JavaScript"),
was designed for Web use and does not open the same security holes
as CGI scripts. Often, server-side CGI programs can be re-implemented
as client-side JavaScript. If a task needs to run on the server
and the site is using one of the second-generation Netscape servers
(FastTrack or the Enterprise server), new work usually should
be done in server-side JavaScript. Existing CGI scripts can be
run subject to the limitations determined by the server security
stance.
| Caution |
If you use client-side JavaScript to replace CGI scripts, your pages can only run correctly on Netscape Navigator or Microsoft Internet Explorer. If you are developing pages for an intranet and you know that only those browsers will be used, you can use client-side JavaScript as needed. If you are developing for the Internet and want to support other browsers, do not replace CGI scripts with client-side JavaScript. Because most browsers do not understand JavaScript, you would still need something at the server level (either a CGI script or a server-side JavaScript program) to do the work. |
Java is an object-oriented programming language developed by Sun Microsystems specifically for use on the World Wide Web. This section describes the strengths and limitations of Java and gives recommendations for its use.
Who Uses Java? As the computer industry moves into the closing years of the 1990s, the software development industry is commonly being divided into two camps: component builders and component users. For example, programmers using an advanced object-oriented language can build OLE custom controls (usually called OCX controls) for use in Windows 95 applications. Sophisticated users can incorporate these controls into a Visual FoxPro database application without having to know the details of how the control is implemented.
Similarly, a programmer can write a plug-in that causes a high-end browser like Netscape Navigator or Microsoft Internet Explorer to handle certain data types in sophisticated ways. An application designer can get that sophisticated behavior by making the plug-in available to the end user, without understanding the details of the plug-in's implementation.
Java is analogous to languages like C++ in that a programmer can
use it to build applets that exhibit complex behavior.
An application designer who is able to write JavaScript can combine
the sophistication of one or more Java applets with client-side
and server-side JavaScript programs to produce a powerful application.
Application designers do not need the technical ability to write
Java programs-but they must be able to understand the behavior
so they can choose which applets to include in their designs.
| Note |
Another technology that is useful for building components is the Navigator plug-in. Using plug-ins, an application designer can write a CGI program, a server-side JavaScript program, or an HTML page that sends a particular data type to the client. The plug-in is invoked by the browser to enable the user to display and interact with the data. Netscape has introduced a new technology, LiveConnect, to enable application designers to integrate Java, JavaScript, and plug-ins on the client computer. This technology affords clear advantages to the application designer who works with good component builders or who can buy off-the-shelf components such as applets and plug-ins that meet his or her needs. |
How to Use Java and JavaScript JavaScript, described later in this chapter, is best used for specifying the flow of control in a program. As a rule of thumb, if you can express the desired behavior in a few lines of pseudocode, JavaScript is probably a better choice than Java. For example, to validate a form, a programmer can write a bit of JavaScript that ensures certain fields are filled in and that the data in the fields meets certain conditions (for example, numeric fields contain numeric data only). The logic for the script is conceptually simple and is shown by the following pseudocode:
if (form.data is valid) send form to server else ask user to correct the offending field
Similarly, server-side JavaScript is appropriate for flow of control issues when the decisions depend on information known only to the server:
book.Title = lookup (SELECT title FROM books WHERE isbn = request.isbn)
if (lookup failed)
write ("There is no book on file with that ISBN")
else
write ("The title is " + book.Title)
On the other hand, suppose the designer wants to display a number of different wallpaper patterns and wants to have the user choose such a pattern from the palette. The logic here is less clear. The user can ignore all the patterns and click Cancel. The user can click Select. Perhaps the user scrolls to another part of the palette. In the real world, the user may select one pattern, then scroll to another part of the palette and select a different pattern, and then scroll back, all before clicking the Select button. This behavior goes well beyond the simple logic of the previous examples-it borders on a small application in its own right. In fact, this task is a good example of an applet.
Java Without Programming While Java was designed with the professional programmer in mind, it was perhaps inevitable that a world that gives us Visual Basic and Visual C++ would also provide a simplified development environment for producing Java. Today's programmer has many opportunities to write Java in a "programmer-friendly environment." The Borland C++ compiler (version 5 and above) includes a "Java mode." Symantec (which makes a sophisticated C++ compiler for both Macintosh and Windows machines) is shipping a Java development system called Café. Natural Intelligence offers a product called Roaster.
Although using these development environments to build Java applets
does not completely replace the need for professional programmers,
these tools do allow such programmers to perform their work much
more quickly and with fewer errors than non-integrated environments
such as Sun's Java Development Kit (JDK).
| ON THE WEB |
http://www.javasoft.com/nav/download/index.html You can get the latest version of the JDK directly from Sun's JavaSoft site. Be sure to get the documentation and tutorial as well-they're downloaded separately from this same page. |
To get started with Java, you can use the JDK from Sun. To use the JDK to write applets that will interact with plug-ins and JavaScript (using Netscape's LiveConnect technology), you need some additional classes and tools that are supplied by Netscape in their LiveConnect/Plug-In SDK.
The crown jewel of LiveWire and, indeed, of much of Netscape's current work, is the JavaScript language. This section provides a short introduction to JavaScript and makes some recommendations regarding who should use it.
What Is JavaScript? Despite the similarity of their names, JavaScript is quite different from Java. JavaScript was developed by Netscape (under the name "LiveScript") to meet the needs of application designers. As described above, many application designers do not have (and do not need) the technical sophistication necessary to write Java programs. They can describe a flow of control and can invoke existing components at key points in that flow.
JavaScript can be run on the client (with suitable browsers such as Netscape Navigator) or on the server (with suitable servers such as Netscape's FastTrack or Enterprise servers).
Who Uses JavaScript? Simple but functionally powerful JavaScript programs may be written by the same sort of users as those who build spreadsheets and spreadsheet macros. If the end user has written applications in a language like Visual FoxPro or Visual Basic, then even sophisticated JavaScript should be within their reach.
When to Use Client-Side JavaScript Client-side JavaScript does not run on all browsers. To use client-side JavaScript effectively in an environment such as the Internet, where a user may come to the site with a browser that does not understand JavaScript, the application designer needs to provide a server-based backup. For example, a client-side script may validate the fields in a form. If the contents are not valid, the form is not sent to the server-instead, an alert appears that tells the user which field must be changed.
The client-side script can be written so that, when the script determines that the contents of the form are valid, a hidden field is set to true. The server might have a CGI script or server-side JavaScript program that looks first for this hidden field. If the server program does not find the hidden field set to true, the server program knows that the client-side script did not run and that the data is validated by the server program.
The advantage of this hybrid design is that browsers like Navigator,
which understand JavaScript, run the script on the client's machine,
avoiding the time necessary to send the data up to the server
and get the results back. An Internet user can still come to the
site with a browser that does not run JavaScript, and their validation
is done on the server (as it is on the many sites that rely on
CGI-based validation).
| Note |
If you add client-side JavaScript to your pages, that code will have to be downloaded to the client even if the browser doesn't understand JavaScript. Most JavaScript functions take only a few tens of bytes-even large JavaScript programs seldom exceed a kilobyte on a single page. If the end user is on a dial-up connection, the JavaScript may add a second to the download time of each page. If the end user is on an ISDN line or other high-speed connection, the download time is negligible. |
To alert the browser to the presence of JavaScript, the JavaScript programmer encloses the code in <SCRIPT>…</SCRIPT> tags. To prevent the contents of the script itself from being displayed on the browser when the browser doesn't understand the <SCRIPT> tag, the developer is expected to embed the entire script in an HTML comment. Listing 2.2 shows a client-side JavaScript variation of the famous "Hello, world!" program, and a bit more.
Listing 2.2 -Description of File
<HTML>
<HEAD>
<TITLE>Listing 3-x</TITLE>
<SCRIPT LANGUAGE="JavaScript">
<!-- hide script from browsers which do not understand JavaScript
function getname(str)
{
alert ("Hello, "+ str + "!");
}
// end the script-hiding comment -->
</SCRIPT>
<BODY>
<FORM>
Please enter your name:
<INPUT TYPE="text" NAME="name" onBlur="getname(this.value)" VALUE="">
</FORM>
Last changed:
<SCRIPT LANGUAGE="JavaScript">
<!-- hide script
document.write(document.lastModified)
// end hide -->
</SCRIPT>
</BODY>
</HTML>
Notice that, by convention, functions are defined in the <HEAD> section. Keeping function definitions in the <HEAD> ensures that the function cannot be called before it is defined.
Note, too, the use of comments to hide the script from older browsers. The order of the comments and tags is critical:
When to Use Server-Side JavaScript and LiveWire Pro Sometimes
the processing required by a script depends on information known
only on the server or the processing requires a capability of
the server. For example, the script may be required to send e-mail
to the site owner, or the script may be expected to write a file
on the server machine. The script may need to read a file or a
database that is stored on the server or even elsewhere on the
Internet. These tasks can be done by using server-side JavaScript.
| Note |
Server-side JavaScript is part of Netscape's LiveWire product. You must have a second-generation Netscape server such as FastTrack or the Enterprise server, as well as LiveWire or LiveWire Pro, in order to run server-side JavaScript. LiveWire Pro includes all of the components of LiveWire, plus a relational database manager and the necessary JavaScript libraries to allow you to connect to the database from server-side JavaScript. |
| Tip |
If your database requirements emphasize the relationship between data, even more than the data content itself, you may want to look into the use of Object Request Brokers, or ORBs. Netscape ONE technology includes the Internet Inter-ORB Protocol (IIOP), an open standard designed to facilitate interaction with ORBs. Netscape has also developed its own Java-based ORB. See Chapter 8, "Distributed Objects and the IIOP," for more details. |
Server-side JavaScript is introduced with the <SERVER> tag. Server-side JavaScript is compiled on the server, so you don't need to take special precautions to allow for older browsers. By the time the page arrives at the browser, the server-side script has run and its results are embedded in the HTML file.
For example, suppose the following lines are included in an HTML page on your server:
<SERVER>
write("<TABLE>")
write("<TR>")
write("<TD>Item 1</TD><TD>Info about Item 1</TD>")
write("</TR><TR>")
write("<TD>Item2</TD><TD>Info about Item 2</TD>")
write("</TR>")
write("</TABLE>")
</SERVER>
This code is compiled on the server and run when the user requests the file. The browser actually sees:
<TABLE> <TR> <TD>Item 1</TD><TD>Info about Item 1</TD> </TR><TR> <TD>Item2</TD><TD>Info about Item 2</TD> </TR> </TABLE>
Of course, server-side JavaScript starts getting interesting when
the dynamically generated information (like the items in the table)
come from a database, a file, or other information known only
to the server at runtime.
| Tip |
If you build server-side JavaScript applications, use LiveWire's Application Manager to install and start them. Figure 2.8 shows a typical page from the Application Manager. Note, too, that the Application Manager is, itself, a LiveWire application, so you can access it from anywhere on the Web (if you have the necessary access permissions). |
Figure 2.8: Use the Application Manager's Configure page to set up installation defaults.
As you put your application together, think about three kinds of information:
Likewise, think about two kinds of action:
Any information you have when you write the pages is a candidate for static HTML. If you want the site visitor to be able to send e-mail to the site owner, just code something like:
<A HREF="mailto:[email protected]">John Jones</A>
If the application requires information or action that is local to the client's computer, use client-side JavaScript but consider backing it up with a CGI script or server-side JavaScript program to deal with browsers that are not JavaScript-aware.
If the application requires the server's information or action, then the only choices are CGI and server-side JavaScript. If the server is a second-generation Netscape server, choose server-side JavaScript for new work because it does not have the same security vulnerabilities as CGI.
If users are given a work in a traditional medium (such as this book) they know from years of experience how to proceed. For the most part, readers start at some page and go from each page to the next. From time to time, readers may refer to the table of contents or the index and change to a different location in the book. Figure 2.9 shows a traditional page-turning system.
Users of hypertext systems such as the Web have some difficulty staying oriented. Some hypertext systems enable the user to leap from one concept to the next, and users may have difficulty keeping track of which site they are on or what choices they have available. The problem appears in all hypertext systems and is exacerbated by the mix of client- and server-side JavaScript, Java, plug-ins, CGI scripts, and static HTML. Figure 2.10 shows how such a system may seem to the user.
As you design the application, continually think about the user's point of view. Test the application on inexperienced users-ask them for their overall impressions of the site. Ask them to find a piece of information and see how many false paths they follow before locating it. Ask the users to go back to a page they've seen before, and see how intuitive such movement is.
Sometimes you need to send information to the client that does not fit cleanly into an HTML page. Perhaps you want to send an advanced graphic that cannot be displayed by the browser or a new kind of data (such as a spreadsheet or presentation graphic) that the user wants to view or even interact with. Instead of trying to build every possibility into every browser (clearly a hopeless task), the designers of browsers chose to allow users to extend the browser at runtime. The first extension is helper applications. The second is plug-ins.
Why Are Helper Applications Necessary? HTML browsers are designed to show HTML well to the user. Most vendors allow their browser to show certain graphics formats, like GIF and JPEG, inline. Vendors like Netscape have extended their HTML browser so that it can access FTP sites, news servers, gopher sites, and e-mail servers.
But no browser can show everything. So the browser developers provide hooks to allow the browser to invoke other programs, called helper applications. To understand how helper applications work, it's important to first understand how Web servers send HTML documents.
To pretend that you're a Web browser, open a Telnet session to your favorite Web site. Most Web servers are set up to listen on port 80. For example, in UNIX you can type:
telnet www.dse.com 80
After the session is open, ask for a document by typing
GET documentName HTTP/1.0
followed by two Returns. For example, to get the default page from the DSE site, type
GET / HTTP/1.0
Remember to press the Return key twice. The contents of the file come up quickly. To slow it down so you can read it, pipe the output of the Telnet command through more. Alternatively, because you're just interested in the HTTP headers, you can ask the server for headers only:
HEAD / HTTP/1.1
Here's a typical response from a HEAD request:
HTTP/1.0 200 OK Date: Sat, 22 Jun 1996 17:57:42 GMT Server: Apache/1.0.5 Content-type: text/html Content-length: 2313 Last-modified: Mon, 17 Jun 1996 16:01:40 GMT
This response says that the request succeeded (status code 200 means "OK"). The entity named in the request has a content type (also known as a MIME type) of text. The subtype is html. This Content-type line is the important one-it tells the browser to interpret what comes after the header as HTML.
Here's another request, this time for a graphic:
HEAD /Graphics/dseLogo1.gif HTTP/1.0
This time the Content-type line in the response is:
Content-type: image/gif
Not surprisingly, the browser understands this line to mean that the upcoming content is an image-specifically, a file in the Graphics Interchange Format (GIF). Netscape Navigator (and nearly every other browser) can handle this format by itself, so the browser displays the image as an inline GIF.
But suppose the Content-type line reports something more exotic, such as video/quicktime, audio/x-wav, or application-x-zip-compressed. These formats are not handled by the browser. Instead, the user has to provide some guidance as to what should be done with the file.
In Navigator, the user provides this guidance by using the Options, General Preferences menu item. The General Preferences dialog box associated with that menu item is shown in Figure 2.11.
| Tip |
While this example shows how to set up helper applications in Netscape Navigator, the same feature is available in nearly all browsers. Unlike Netscape and Microsoft plug-ins, helper applications are available for most graphical Web browsers. |
Using this dialog box, the user can specify an application that should be launched to handle an entity of a particular MIME type. These helper applications are platform- and operating-specific. For example, a Windows 95 user may view video/mpeg with MPEGPLAY, while a UNIX user may use mpeg_play.
Figure 2.12 shows an example of an MPEG movie playing in a helper application.
Figure 2.12: A helper application opens its own window separate from the browser.
How Are Plug-Ins Different? When a helper application launches, it opens its own window, puts up its own menu bar, and generally behaves as a separate application-which it is! In an ideal world, the user wouldn't have to know that he or she was leaving the browser and switching to a new application. The contents of the new file would appear inline, just like GIF images are handled now.
In this respect, at least, you are moving toward an ideal world. Netscape and Microsoft's browsers both support plug-ins-code resources that share the browser window. Figure 2.13 shows how a VRML scene is rendered in the Netscape plug-in.
Figure 2.13: A plug-in shares the browser window, giving a more integrated appearance.
Not only does the plug-in appear to be integrated into the browser window, but also the plug-in Application Programming Interface (API) enables the plug-in programmer to call and be called by the browser itself. Netscape has built upon this foundation in its new technology, LiveConnect.
How Does LiveConnect Work? Starting with Netscape Navigator 3.0, Netscape enables the application developer to link plug-ins, Java applets, and JavaScript together on the client's machine. LiveConnect is based on the Java Runtime Interface, which allows:
Figure 2.14 illustrates LiveConnect.
In addition to using LiveConnect, the application developer can pass parameters directly from HTML to a plug-in. For example:
<EMBED SRC="theMovie.avi" WIDTH=100 HEIGHT=200 SPEED=SLOW>
tells the plug-in that handles the AVI movie to set SPEED to SLOW. Parameters are specific to each plug-in.
After issues of capability are solved (for example, you can't look up a database from the client machine), the application designer focuses on available processor power and network bandwidth. Trends in the computer industry suggest that both processor power and network bandwidth are climbing, but processor power is increasing at a faster rate than bandwidth. Although the PowerPC and the 200 MHz Pentium may soon be commonplace, the desktop T-1 is likely to be a bit farther off.
Here are some rules of thumb to use when deciding which portions of the application to run on the server and which on the client:
When to Use Plug-Ins Recall that plug-ins are used to process special data types on the client machine. Plug-ins make the most sense when the data cannot be processed in the browser. Adobe's PDF plug-in, shown earlier in this chapter in Figure 2.6, is a good example of this sort of plug-in.
Plug-ins also make sense when the information can be transmitted in compact form and expanded on the client machine. The Virtual Reality Modeling Language (VRML) works like this: VRML is a compact description of complex scenes. The scenes are produced by plug-ins or helper applications.
When to Use Java As mentioned in the preceding section, Java is appropriate when the task is sufficiently complex to demand the talents of a professional programmer. Java is also a good way to protect complex algorithms if the designer does not want them to become common knowledge. Client-side JavaScript is embedded in source form in the HTML page. Like client-side JavaScript, Java runs on the client machine. Unlike client-side JavaScript, the source is not present at runtime-the client browser gets only the compiled bytecodes, which it uses to produce output for the end user.
When to Run Server-Side JavaScript When a portion of an application can be run on either the server or the client, the designer may have some reasons not to keep the application on the client. Like Java, server-side JavaScript does not give the source code to the end user. Thus, server-side JavaScript preserves the confidentiality of the source.
Because server-side JavaScript runs on the server, it can access special resources over the Internet. The obvious examples are file servers and database servers. Other examples include special-purpose computers, such as machines serving artificial intelligence and knowledge-based applications and machines performing special graphics calculations. Many special-purpose computers do a better job at floating-point calculations than the typical desktop computer. Specialized applications like finite element analysis (often used in mechanical engineering) benefit by being run on arrays of servers rather than being sent to the client. Server-side JavaScript can call programs on machines running on an intranet and can link to programs written in languages like C and C++.
Server-side JavaScript also has the advantage of being browser-independent. The output of a server-side JavaScript program is HTML and can be designed to be standard HTML 2.0 or 3.0 without vendor-specific extensions. When used this way, server-side JavaScript enables the designer to add special features without being overly concerned about the capabilities of the user's browser.
When to Run Client-Side JavaScript Some Webmasters have decided to write for the Netscape Navigator audience and are willing to include features on their pages that compromise the effectiveness of the page when used with non-Navigator browsers. Other Webmasters are willing to include Netscape-specific features, such as frames, but only if the page still looks good to users without Navigator.
Client-side JavaScript is a powerful tool, but it is available only on Netscape Navigator and Microsoft Internet Explorer (under the name "JScript"). The Webmaster can use it to provide nonessential services, such as animation. The Webmaster can also use it to provide essential services, such as form validation, as long as the service is backed up by server-side JavaScript, CGI scripts, or server-side includes, so that users without Navigator do not miss out on the feature.
When used this way, client-side JavaScript adds to the workload of the Webmaster (because essential services must be duplicated on the server), but increases the functionality of the page (because essential services do not have to use network bandwidth if the client is JavaScript-aware).
Over time, it seems likely that the percentage of users with a
browser that does not understand an embedded language like JavaScript
will decrease. At some point, client-side JavaScript may become
part of the accepted set of browser capabilities, in much the
same way as HTML 2.0 is expected of any credible Web browser today.
When that day arrives, look for the number of pages that take
advantage of client-side JavaScript to climb dramatically.
| ON THE WEB |
http://www.w3.org/pub/WWW/MarkUp/Wilbur/features.html Get the latest information on HTML 3.2 from this site. Note that the <SCRIPT> tag is in the standard and is marked as "reserved for future use with scripting languages." Expect many HTML 3.2-compliant browsers to support JavaScript. |
This chapter provides an overview of the kind of pages that can be built with Netscape ONE technology, and especially with LiveWire and LiveWire Pro. Options include static HTML, CGI, Java, JavaScript on the client, JavaScript on the server, and plug-ins. Although most users use a Netscape Navigator or a Navigator-compatible browser (such as Microsoft Internet Explorer), many Internet users' browsers do not support plug-ins or client-side JavaScript. This fact means that the Webmaster must decide to ignore that portion of the audience or offer alternative ways of providing essential services (such as CGI scripts or server-side JavaScript).
Within the SDK, you'll find reference guides for HTML, tools for Java, and descriptions of both client-side and server-side JavaScript. You'll also find the LiveConnect/Plug-In SDK. Later chapters of this book show how to install and use each of these components to build an integrated network-centric application. Start with the simpler components, such as HTML and client-side JavaScript. As you gain experience, add Java applets, server-side JavaScript, and database access in order to satisfy your application requirements.