FoxWeb Overview

FoxWeb is an application framework that enables programmers to leverage the power of the Visual FoxPro programming language and database engine to create applications that run over the Internet. Its programming interface was designed to protect you from having to worry about the complexities of CGI programming, without taking away the control that is necessary in order to create powerful applications. If you have ever programmed a web application and dealt with the intricacies of CGI programming, you are already familiar with some of the functionality offered by FoxWeb's programming interface. If you haven't, you'll be pleasantly surprised at the simplicity of the programming involved.

Conventional vs. Web Applications

FoxWeb uses a different paradigm than conventional VFP programs. Because of the nature of the World-Wide-Web, there is no way you could take an existing FoxPro application and just get it to run over the web. Web browsers receive information in a language called HTML (Hypertext Markup Language) and send information back to servers using HTML forms. Web applications must interface with Web browsers by reading the input of HTML forms, and formatting output content as HTML text. In order to convert an existing VFP application for Web use, you would have to re-write the user interface, including all code dealing with input and output. Other procedures handling the logic of the application, such as queries, data-updates, etc., can remain unchanged.

Web Programming Concepts

The FoxWeb programming interface provides functions that make it easy to read incoming data and dynamically create HTML output, which is sent back to the user's browser. In order to write FoxWeb programs it first necessary to obtain a general understanding of HTTP -- the protocol used to transfer Web content, such as text and images over the Internet. This topic also attempts to explain the differences between static and dynamic content.

The HTTP Protocol

The HTTP protocol is a request/response protocol. This means that a client, such as a web browser, sends a request to the web server in the form of an HTTP request message. This request contains, as part of its content, a request method, a Uniform Resource Identifier (URI), and protocol version followed by a MIME-like message. Uniform Resource Identifiers are simply formatted strings, which identify -- via name, location, or any other characteristic -- a resource - commonly known as a URL.

Once this message reaches the Web server, an attempt is made to satisfy the request. The server responds with a status line, including the message's protocol version and a success or error code and the requested resource. If there are embedded images or objects in the HTML response, the Web browser makes subsequent requests for each embedded object.

Depending to the resource requested in the URL, the server either reads a static file, such as an HTML page or GIF image from its hard-disk, or executes a server-side program, which creates dynamic content to be served back to the browser.

As a FoxWeb programmer you do not need to know much about HTTP. Although HTTP drives all content transportation over the Web, FoxWeb abstracts its details and provides a simplified programming interface that makes it easy to create Web-based applications. The main points that you need to remember from this discussion is that Web-applications, unlike other types of applications, do not maintain a continuous connection between the user interface component (in this case the browser) and the back-end application logic component (the Web application server). Information is exchanged in distinct interactions, which occur when the user clicks on a hyper-link or submits an HTML form.

Static vs. Dynamic Content

Static Content
The Web originated as a medium for linked static content, which are pre-authored pages that reside on a server's hard disk and are sent to users upon request. Web site administrators must explicitly modify their HTML pages in order for the content that the Web server sends to a client browser to change. In the static model, a client browser uses HTTP to request an HTML page or other resource from the Web server. A server receives the request and sends the HTML page back to the client browser, which formats and displays the page. Although this model is adequate for many applications, it provides only limited interaction between the user and the Web server and is not suitable for serving data-intensive content. The information served is only as current as the last time someone manually edited the HTML pages.
Dynamic Content
With Common Gateway Interface (CGI), Internet Server Application Programming Interface (ISAPI), and other gateway interfaces, a user can send an HTTP request to program on the server rather than requesting a static HTML file. When such a request arrives, the server runs the specified program, providing to it the information that was passed with the request; for example, fields that a user entered by filling out an HTML form. The program then parses the values for meaningful information, and generates output in HTML to send back to the client. FoxWeb provides a framework that allows programmers to easily interact with Web browsers and generate dynamic content based on information in FoxPro and other databases.

How FoxWeb Works

FoxWeb in general terms works in a very simple manner: The user calls a FoxWeb script by clicking on a link, submitting an HTML form, or manually typing a URL in a Web browser. The URL contains information that indicates the script to be run as well as some optional arguments, which are passed on to the program along with any form fields. The request is received by the Web server, which passes it on to FoxWeb. FoxWeb parses the URL and other request information and runs the requested script. The information sent along with the request is made available to the script via FoxWeb's Request object. FoxWeb processes the requested script from top to bottom, executes any code included in it, and sends a Web page to the browser.

Because your scripts run on the server rather than on the client, your Web server does all the work involved in generating the HTML pages sent to browsers. Server-side scripts cannot be readily copied because only the result of the script is returned to the browser. Users cannot view the script commands that created the page they are viewing.


© Aegis Group