Microsoft FrontPage: A Technical Perspective

March 1, 1996

Introduction to FrontPage

FrontPage™ from Microsoft® is an integrated, vendor-independent, cross-platform, client/server visual authoring environment for World Wide Web sites, either on the public Internet, or internally within organizations. Using FrontPage, any experienced user of typical Windows and Macintosh applications can easily and rapidly create, deploy, maintain, and administer a sophisticated web site (or, simply, "web"), including professional quality web pages and interactive functions normally found only on advanced sites.

There is both a client and a server portion to the FrontPage software. FrontPage Client, which is available for Windows 95® and Windows NT®, and soon to be available on the Macintosh®, is the web authoring environment itself, with a state-of-the-art graphical user interface. The server portion is a set of software additions, called the FrontPage Server Extensions, that connect to any standard web server and enable FrontPage Client to operate. The Server Extensions also implement the interactive features of the web as seen by a web browser. Microsoft already provides Server Extensions for many of the leading commercial and shareware/freeware web servers on various popular hardware/software platforms, (including Windows 95, Windows NT, and various versions of UNIX), and support for most of the other popular web servers and server platforms (including Macintosh web servers) are slated for release over the next few months.

Just as any web browser can view the content of any web server, any copy of FrontPage Client can author the content of any web server equipped with the FrontPage Server Extensions. The only requirement is that there be a TCP/IP network connection between the client workstation and the server, the same requirement as for communication between a web browser and server. Thus, from the desktop, an author may develop and contribute to an internal workgroup web server behind the corporate firewall, a public enterprise web server outside the firewall, or a web server hosted at an external location that is elsewhere on the Internet.

Note: Transmission Control Program/Internet Protocol (TCP/IP) is the universal networking protocol used by the global Internet. Many corporate LANs also use TCP/IP, for ease of communication with external sites. All other Internet protocols, such as the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP), are layered on top of TCP/IP.

For convenience, Microsoft provides a personal web server and matching Server Extensions with the FrontPage Client, and the complete package is referred to as the FrontPage Desktop, or simply FrontPage. The FrontPage Desktop package allows the author to develop and test a web on his or her personal computer (on the desktop, or perhaps on a laptop computer while traveling), and later use the FrontPage "Copy Web" function to transfer the entire completed web across the network to any other web server equipped with the FrontPage Server Extensions. Alternatively, the author can deploy the web directly from the desktop, for the corporate workgroup, or as a public site on the global Internet.

FrontPage was designed from the start to be open and vendor-independent for every functionality that is not at the core of web authoring itself. Thus, FrontPage will allow authoring for all of the leading web servers, and generate webs that can be viewed by all leading web browsers. In future releases, FrontPage will also provide vendor-independent, "plug-in" support in the Server Extensions for the leading full-text search engines (in addition to the freeware search engine already integrated into the Server Extensions), relational databases, electronic payment systems, etc. Further, customers and third parties can design and resell (royalty-free) custom wizards, templates, and WebBots (see below) for FrontPage, to address the needs of custom applications and vertical markets. FrontPage is a web authoring platform into which complementary technologies can be infused, and on which entire classes of web applications can be built.

FrontPage Client integrates all of the functions typically required to develop and administer a web, in a seamless environment architected from the ground-up for ease of use and comprehensive functionality. These include:

The remainder of this document presents an introduction to the Web, and a detailed technical description of the features and architecture of FrontPage.

Introduction to the World Wide Web

The World Wide Web (or simply "the Web") was invented in 1989 by Tim Berners-Lee at CERN (see note below). It refers to all computers on the global Internet that serve up interactive information with a software program called a web server (In technical circles, the term "HTTP daemon" (HTTPD) is often used instead of "web server."). A single web server can support multiple webs. End-users can view information on web servers by running a program known as a web browser program on a "client" computer anywhere on the Internet. Web browsers and web servers communicate using the Hypertext Transfer Protocol (HTTP), which is layered on top of TCP/IP. Text-based web browsers have been available since the birth of the Web, but the Web architecture moved into the mainstream with the advent of Mosaic, an extremely popular web browser with a graphical user interface, developed at NCSA (The National Center for Supercomputing Applications (NCSA) is located at the University of Illinois at Urbana-Champaign.). Also, both CERN and NCSA developed freely available web server implementations that have served as the basis for many shareware and commercial products.

Note: Conseil Europeen pour la Recherche Nucleaire, now called the European Laboratory for Particle Physics, is still referred to as CERN. Headquartered near Geneva, Switzerland, it is the birthplace of the World Wide Web. CERN has transferred its Web research and development activities to the World Wide Web Consortium (W3C) based at the Massachusetts Institute of Technology Laboratory for Computer Science (MIT/LCS), and to the Institut National de Recherche en Informatique et en Automatique (INRIA), the French National Institute for Research in Computer Science and Control.

Web servers and browsers work equally well on private networks, which are usually not accessible from the global Internet, as a foundation for intracompany electronic communications. Private web servers, typically behind firewalls (a firewall is hardware/software that typically allows fairly liberal access to the Internet from inside of a company, but only very restricted access to the company's computers from others on the Internet.), are not considered part of the World Wide Web per se, but still use the Web architecture and technology. Note that the same web browser software can be used both for browsing internal corporate web servers and public web servers on the Internet.

Although web servers can deliver any type of document on request, the primary web document format is Hypertext Markup Language (HTML), which is based on Standard Generalized Markup Language (SGML). The HTML format includes text, plus tags that denote document structure, appearance, inline graphics, and hyperlinks that refer to other documents on the same web server or on another web server, on the corporate network or anywhere on the Web. When viewing an HTML document using a web browser, an end-user may choose or "click" the mouse on a hyperlink, which causes the web browser to fetch and display the document referred to in the hyperlink.

On the Web, the word document refers to an HTML file, text file, or any other type of file (sound, animation, movie, etc.) that might be delivered by a web server. Every document on the Web has a Universal Resource Locator (URL) with which it can be accessed. For example, "http://www.microsoft.com" is the URL for Microsoft's "home page" on the Web. The home page of a web is the main HTML document that directly or indirectly leads to the other files of interest within that web.

The infrastructure software for web-based information dissemination—web servers and web browsers—is readily available from freeware, shareware, and commercial sources. However, software tools for web content creation, management, and maintenance are typically much more difficult to use, are not integrated, and are missing key functionalities, whether the tools are commercial products or non-commercial freeware/shareware. This web authoring area is the focus of FrontPage, which addresses these problems.

FrontPage: A Client/Server Web Authoring Environment

FrontPage is fundamentally a client/server authoring tool. This architecture provides a number of benefits, including remote authoring, multi-user collaborative web development, and platform independence between the client workstation and the server.

Figure 1. FrontPage architecture

In this section, we discuss the client/server nature of FrontPage in greater detail. First, we define more precisely the nature of the client and server software that comprise FrontPage. We then characterize FrontPage's vendor-independent web server support, and describe how the FrontPage Server Extensions interact with the web server. Finally, we present the communication mechanism used between the FrontPage client and the Server Extensions. See Figure 1 for an overview of the FrontPage client/server components.

Client vs. Server

The FrontPage Client software consists of the user-visible FrontPage authoring environment and its associated infrastructure. This includes the FrontPage Explorer, FrontPage Editor, To Do List, wizards, templates, and user interfaces for WebBots. These components of the FrontPage Client are described in more detail in separate sections below.

The FrontPage Server Extensions consist of a small number of executables that are installed on the same computer as the web server. The Server Extensions provide three major functions:

    They add functions to the web server that are required by the FrontPage Client, such as storing documents, updating the To Do List, and computing the graph of link relationships among the documents within the web.
  1. They provide common application program interfaces (API's) for functionalities whose implementations tend to differ between web servers, such as permissions, clickable imagemaps, and web server configuration information.
  2. They implement interactive functions for end-users who browse the web, such as full-text search, threaded discussion groups, and web registration.

The FrontPage Client communicates with the Server Extensions via the web server itself. This mechanism is described below.

Server Extensions Architecture

The FrontPage Server Extensions are architected to interface with any standard web server software. This includes shareware/freeware servers such as those from CERN and NCSA, and commercial web servers such as Internet Information Server from Microsoft Corporation, WebSite from O'Reilly & Associates, Inc., NetSite from Netscape Communications Corp., and WebServer from Open Market, Inc. Furthermore, the Server Extensions are designed to be easily ported to all popular hardware and software platforms, for cross-platform web server compatibility.

For most web servers, the FrontPage Server Extensions are accessed by the web server via some variant of the Common Gateway Interface (CGI), the near-universal web server extension mechanism. The implementation of CGI differs somewhat among web servers and platforms. For example, most UNIX web servers invoke a CGI extension by running it in a separate fork, whereas some Windows NT web servers support a Dynamic Link Library (DLL) variant of CGI-style communication that incurs less overhead. But the information flow is similar for all CGI implementations: various user-driven values and environment parameters are passed to the CGI extension using a block of name/value pairs, and the CGI extension program returns a result in HTML format. This mechanism is sufficiently general to allow rich communication between the FrontPage Client and the FrontPage Server Extensions.

In certain cases, the FrontPage Server Extensions must themselves initiate communication with the web server. The principal examples are:

Web servers from different vendors typically do not implement the above features in exactly the same way. For example, the NCSA web server reads a text file on the server to determine permission settings, whereas WebSite reads the Windows 95 or Windows NT registry to find permissions.

Because of these differences among web server implementations, the FrontPage Server Extensions must typically be changed somewhat to support each additional vendor's web server. These differences are isolated in drivers within the Server Extensions, allowing 80-90% of the Server Extensions program code to remain unchanged between web servers. For convenience, a given edition of the Server Extensions will often build-in drivers for more than one vendor's web server on the target server platform.

Client/Server Communication

The FrontPage Client permits authoring and administration of a given web by communicating with the FrontPage Server Extensions installed alongside the web server for that site. That web server might be located elsewhere on the global Internet, on the same corporate LAN as the client, or on the same workstation as the FrontPage Client itself. If a firewall separates the client and server, the FrontPage Client uses the appropriate proxy server to access the web server.

In all of these cases, FrontPage uses HTTP, the same protocol for client/server communication as is used between web browsers and web servers. The FrontPage Client sends an HTTP "POST" (see note below) request to the web server with a URL that specifies the appropriate executable program in the FrontPage Server Extensions, and passes along any pertinent data as part of the "POST." The web server receives the "POST," invokes the FrontPage Server Extensions, and passes along the parameters that were included in the request. The Server Extensions process the data, and send back any return values as part of the "POST" reply message.

Note: The HTTP "POST" request is typically used by a web browser to "post" data typed into a form by an end-user to a CGI program that will interpret the data and return a response in HTML format. More generally, "POST" instructs the web server to invoke a given CGI program with some given parameter values, and return the HTML results to the web browser for display to the end-user. The CGI program to be invoked is specified with a URL that is part of the "POST" request.

In this way, FrontPage implements a remote procedure call (RPC) facility on top of the base-level HTTP "POST" request mechanism. FrontPage Client invokes a "procedure" in the remote Server Extensions, and the procedure's results are returned to the Client. This mechanism is used for such tasks as sending a document to the web server for storage, retrieving the contents of the To Do List, and many others.

Note that FrontPage does not use or require the HTTP "PUT" request. As described in the HTTP specification, "PUT" is designed to send a document to the web server. However, few web servers actually implement "PUT," which interferes with cross-vendor compatibility. Consequently, FrontPage uses the universally-implemented, and equally serviceable, "POST" request of HTTP for all communication with the Server Extensions.

Security

FrontPage provides specific security support in three areas:

    Controlling access to a web, by end-users, authors, and administrators.
  1. Proxy support, to permit authoring through a firewall.
  2. Encryption of all client/server communications.

These security features are further described below.

Permissions

The FrontPage Server Extensions support three levels of access to a web: end-user access (browsing the web), authoring access (accessing, updating, and maintaining the web using FrontPage), and administrative access (updating end-user, author, and/or administrator permissions).

To achieve control over access, FrontPage relies on the permissions mechanism built-in to the web server itself. Most web servers support the notion of realms, where each realm corresponds to a particular set of permissions. Furthermore, most web servers allow access to a given realm based on a list of usernames and passwords, a list of IP address masks, or both.

FrontPage designates one realm to correspond to end-user access, another realm for authoring access, and a third realm for administrators. The FrontPage permissions model supports any combination of username/password and IP address mask schemes. The usernames, passwords, and IP address masks can be manipulated by the user in the FrontPage Explorer using normal point-and-click techniques.

Proxies

It is often convenient to use the FrontPage Client to author against (or copy a web to) a web server that is on the other side of a firewall. This can occur either going "outbound," such as authoring against an external enterprise web server outside the firewall, or going "inbound," such as authoring against an internal corporate web server behind a firewall while traveling on the road.

FrontPage Client handles both of these cases. For accessing a given web server, FrontPage allows the author to specify a proxy server (machine name and optional port number) through which all communications with that web server should be routed. (FrontPage Client saves this proxy information for future use.) For either outbound or inbound authoring, the FrontPage Server Extensions will typically require a username/password for authoring against that web. This authentication challenge will simply be reflected back to FrontPage Client via the proxy, and the username/password provided by the author will be supplied to the proxy and the web server by the Client. Thus, once the author has supplied the proxy information for accessing a given web server, all proxy communication is handled automatically, and the author need not even be aware that a proxy server is in use.

Encryption

All communications between the FrontPage Client and the FrontPage Server Extensions are automatically encrypted. This security is useful when authoring against an internal corporate web server (behind a firewall) while traveling on the road, where non-public data may be traveling between the FrontPage Client and the FrontPage Server Extensions over the (unsecure) global Internet.

Note: The encryption method is proprietary to FrontPage. It is quite difficult to break, but meets government requirements for export outside of the USA. Going forward, as the Secure HTTP specification proposed by Enterprise Integration Technologies (EIT), and/or the Secure Sockets Layer (SSL) proposed by Netscape Communications Corp., become more universally supported by web server vendors, we expect to support one or both of these emerging security standards for secure communication.

FrontPage User Interface

FrontPage Explorer

FrontPage Explorer forms the framework of the FrontPage Client software. It is normally the program that an author directly invokes to use FrontPage, and all features of the FrontPage Client (including the FrontPage Editor, To Do List, templates, wizards, and WebBots) can be directly or indirectly accessed from the FrontPage Explorer. The Explorer allows the author to view and manipulate a given web as a whole. The screen appearance of FrontPage Explorer is shown in Figure 2.

Figure 2. FrontPage Explorer

Some of the major features provided by FrontPage Explorer are:

FrontPage Editor

FrontPage Editor allows the user to create, retrieve, and save HTML pages, including pages containing WebBots and clickable imagemaps. The Editor also acts as a mini-browser, and can easily import pages from anywhere on the Web into the web being modified. The screen appearance of FrontPage Editor is shown in Figure 3.

Figure 3. FrontPage Editor

Some of the major features provided by FrontPage Editor are:

To Do List

The FrontPage Client includes a To Do List, which lists all of the tasks remaining to complete the web site. Tasks can be automatically added by wizards (see below), or may be manually added, deleted, and modified by authors. The screen appearance of the To Do List is shown in Figure 4.

Figure 4. To Do List

The major features of the To Do List include:

Wizards

Wizards provide a fast and flexible means to create a sophisticated and attractive web, part of a web, or a single page. A wizard is a software module that solicits answers and choices from the author using one or more dialog boxes, generates one or more web pages, images, and/or other document types in response to those answers, and uploads all of those documents to the web server. Once the pages have been created, the author may customize, add, delete, and modify the resulting web or page. Thus, a wizard provides a useful and sophisticated starting point for further web development.

The wizards included with FrontPage are:

Anyone may create custom wizards for FrontPage using Microsoft's Visual Basic or Visual C++, using the documentation, API's, and examples in the FrontPage Developer Kit. Custom wizards leverage the OLE 2.0 methods provided by the FrontPage Client. Such wizards are then stored on the client workstation, where they are automatically hooked into FrontPage using OLE 2.0 automation.

Note: OLE 2.0 automation provides access to wizards in the Windows edition of FrontPage (for Windows 3.1, Windows 95, and Windows NT). A similar capability will be used for wizards in the Macintosh edition of FrontPage.

Templates

Templates are time-saving individual pages, sub-webs, or entire webs that provide the framework to fill a particular need. Templates can also be used within an organization to encourage consistency of style and content, much like style sheets in a word processor. FrontPage includes several web templates (customer support, personal web site, etc.), and over 20 page templates (press release, glossary, etc.).

Templates can be easily created using FrontPage itself, and then saved to the client workstation in a particular manner such that the templates become automatically hooked into the FrontPage Client. This information is detailed in the FrontPage Developer Kit, mentioned above. Note that templates are easier to create than wizards, since no programming is required to create a template.

FrontPage WebBots: Smart Page Objects

Bots Eliminate Programming

One of the key features of FrontPage is the notion of WebBots. A WebBot™ (or, simply, "bot") is an active object that is dropped into a page, and encapsulates interactive capabilities that would traditionally require that custom programs be installed on the web server using the CGI mechanism. Thus, bots allow non-programmers to create sophisticated, interactive webs without the need for programming. The great majority of programming capabilities currently found in webs could be eliminated with the use of the bots in FrontPage.

For example, many webs include a facility that allows the end-user type in a few words, and then click on a button to perform a full-text search across all pages in a web. The search returns a list of hyperlinks to all documents within the web that contain those words. To implement this feature in the traditional fashion, the author must: (1) create an HTML form that initiates the search, (2) install a third-party full-text search engine on the web server (such as the freeware version of WAIS—see note below), and (3) write a CGI program on the web server that connects the HTML form to the full-text search engine. With FrontPage, the author need only insert a Search Bot into a page, answer a few questions in the bot's configuration dialog box, and the full-text search facility is fully operational in the web within moments.

Note: Wide Area Information Service (WAIS) began as an MIT research project by Brewster Kahle to provide full-text search capabilities, and eventually resulted in a freeware, web-compatible facility. Many webs that today provide full-text search capabilities use this freeware version of WAIS. The WAIS technology has also been greatly improved and strengthened as commercial-quality OEM software from WAIS Inc., founded by Mr. Kahle. There are also several other commercial web-compatible full-text search engines, from such companies as Verity Inc., Fulcrum Technologies Inc., Personal Library Software (PLS), and Architext Software.

Most bots are added to a page using the Insert/Bot menu item in the FrontPage Editor. When a bot is inserted, a dialog box (or multiple dialogs) are presented to the user to configure the bot, and then a WYSIWYG representation of the bot (which often depends on the user options selected) is visible in the Editor at that position in the page. A few of the bots are specifically associated with forms, and are accessed via the form properties dialog box rather than the Insert/Bot menu item. When the end-user browses to a page that includes a bot, the interactive or programming properties of the bot are manifest. The bots themselves are stored into a page using a specially-formatted HTML comment, although this representation is not normally seen by the FrontPage author.

Standard Bots Included with FrontPage

FrontPage includes the following standard bots:

Example Bot

As an example, Figure 5 shows the dialog box that is displayed when a Timestamp bot is inserted into a page, from within the FrontPage Editor.

Figure 5. Configuring a Timestamp Bot

The preview representation of that Timestamp Bot is:

September 29, 1995 10:45 AM

The above preview presentation string is also how the bot will appear when the end-user browses to the page. The normally unseen HTML comment representation of the bot within the generated page is:

<!--VERMEER
   BOT=Timestamp
   S-Type="EDITED"
   S-Format="%B %d, %Y %I:%M %p"
 -->

We use SmartHTML™ as the name for our HTML document format that allows for embedded bots; i.e., standard HTML with specially-formatted embedded comments that denote bots. Note that except for the leading and trailing comment characters, bots are formatted in the same manner as HTML tags and attributes.

Bot Implementation

The server programming that implements each bot is embedded in the FrontPage Server Extensions. Thus, any web server that has the Server Extensions installed for authoring also implements all of the bots for the benefit of end-users who browse the authored web.

When FrontPage Editor saves a SmartHTML page back to the server, the Server Extensions scan the page to determine if any bots are present. If there are, two copies of the page are actually saved to the server: one copy is in SmartHTML and contains the embedded bots, and the other copy is in standard HTML and includes the results of evaluating the bots. A SmartHTML engine, which is part of the Server Extensions, evaluates the bots to generate the standard HTML version of the page.

Thus, in the Timestamp Bot example above, the SmartHTML version of the page contains the HTML comment that denotes the bot parameters ("<!--VERMEER," etc.). The SmartHTML engine evaluates that bot (and any other bots on the page) and generates a standard HTML page that has the actual timestamp ("September 29, 1995 10:45 AM") in place of the bot representation.

The architecture of FrontPage allows for both "static" and "dynamic" bots. A static bot is one whose evaluated appearance does not change when the page is fetched by an end-user's browser (e.g., the Include Bot), but might of course change in response to an action taken by an author (e.g., modifying the page that is included). A dynamic bot is one that must be evaluated each time the page is fetched; for example, a page element that is always dynamically fetched from a database, or a bot that evaluates to a message of the form, "This page has been fetched 2609 times."

The advantage of static bots over dynamic bots is that no additional processing is required at fetch time. The web browser simply requests a pre-computed HTML page. Dynamic bots, on the other hand, are a powerful mechanism that allows the page content to change based on real-time data, user preferences, the browser being used, etc.

As it turns out, all of the standard bots implemented in the first release of FrontPage are static, though the architecture supports dynamic bots. (The Search Bot does return dynamic search results when invoked, but it is technically a static bot because the appearance of the search form itself is static by the time a web browser fetches the page.) However, future releases of FrontPage will include dynamic bots, including those that perform database updates and queries.

Custom Bots

A future release of FrontPage will allow customers and third parties to create custom bots for specialized purposes. A custom bot (and, indeed, each of the standard bots included with FrontPage) has three implementation elements:

The implementation of a bot can produce any of three different types of results back to the web server, which in turn sends those results to the web browser:

    Inline. An HTML fragment that is placed into the page at the same point where the bot itself appears. For example, the Search Bot returns its results directly into the search page at the place where the search form (bot) appeared.
  1. Replacement. A complete document (usually an HTML page) that replaces the page that invoked the bot, in the user's web browser. For example, a custom bot might return a large table of results from a database query, where those results completely replace the page that invoked the query, like following a hyperlink.
  2. Redirect. An HTTP reply that causes the web server or browser to "redirect," and transparently request the document corresponding to a different specified URL. Thus, a custom bot could (for example) write a complete HTML page of results to a file, and then return a redirect to the URL of that page. Alternatively, a custom bot might redirect to one of several URL's of static pages corresponding to different result outcomes.

The forthcoming FrontPage Developer Kit will include all of the components and documentation needed to create custom bots, including examples.

FrontPage in a Larger Web Development Context

For many authors, FrontPage is not used alone in the creation of an effective web. In some cases, an author may wish to use FrontPage for ongoing maintenance of a "legacy" web, originally created without FrontPage. Other authors may want to use FrontPage in conjunction with other, more specialized web tools. Still others might wish to leverage custom CGI scripts within the web. FrontPage supports all of these scenarios, as outlined below.

Moving Content Into FrontPage

With FrontPage, an author can easily create and maintain a web from scratch. However, the author can also use FrontPage to update a legacy web that may have been created using other tools (or completely by hand). When the FrontPage Server Extensions are installed for a web server whose content area contains non-FrontPage web(s), the Server Extensions automatically gather the additional information used by FrontPage, and enable the content for use with FrontPage.

Alternatively, after installing the FrontPage Server Extensions, the author can copy a legacy web into the web content area, and then alert FrontPage to the presence of the new legacy content with the "Recalculate Links" command in the FrontPage Explorer.

Moving Content Out of FrontPage

Once FrontPage has been used to edit web content, the author is not locked-in to the use of FrontPage. FrontPage stores all web files in the standard manner assumed by web servers—as HTML files, GIF files, etc., organized into directories—plus some additional information (such as cached link relationships between documents). The FrontPage Server Extensions and other FrontPage-specific files can be easily removed from the web, if desired. If this is done, the bots and clickable imagemaps are automatically disconnected (since these features require the presence of the FrontPage Server Extensions), but the documents of the web continue to be browseable and editable with other tools.

Using FrontPage Together with Other Tools

FrontPage can easily be used in conjunction with other web authoring tools. For example, a newspaper publisher might use proprietary software that converts news stories into HTML pages. If content is added to the web from outside sources or external programs, FrontPage can still be used for documents already recognized by FrontPage. In addition, to allow FrontPage to recognize the externally-added content, the author can run the "Recalculate Links" command from the FrontPage Explorer at any time. This command searches the entire web content area for any new documents, and updates the FrontPage file structures accordingly.

Using FrontPage with Custom CGI Scripts

Although FrontPage WebBots cover most of the interactive programming features that users typically wish to add to webs, there are many cases where custom CGI scripts continue to be useful. For example, a company might wish to program a CGI script that allows an end-user to access corporate database information via the web. In a future release of FrontPage, direct database access will be provided by standard bots, but in the current version of FrontPage, a custom CGI script can be used.

FrontPage makes it easy to invoke a custom CGI script. After an author lays out a WYSIWYG form in the FrontPage Editor (with, potentially, text input fields, scrolling text boxes, checkboxes, radio buttons, drop-down pick lists, and pushbuttons), the author can specify the action to be taken by that form. One of those actions (in addition to the Discussion Bot, Registration Bot, and Save Results Bot) is to invoke a custom CGI script on the server. The author then provides the URL of the CGI script.

Alternatively, to make a CGI script more configurable and easy to use, a custom bot can be implemented in place of the CGI script (in a future release of FrontPage). See the previous section for details.

Copyright © 1996 Microsoft Corporation. All rights reserved.

FrontPage, WebBot, and SmartHTML are trademarks of Microsoft Corporation.