FoxWeb สำหรับผู้ใฝ่หา Webserver FoxScript

http://www.foxweb.com/document/
http://www.foxwebent.com/
FoxWeb สำหรับผู้ใฝ่หา Webserver FoxScript

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. Adding FoxWeb Code FoxWeb code is simply a Visual FoxPro code block, able to utilize virtually any command in the FoxPro language. Among other things, it can be used to search tables, manipulate data, perform calculations and create HTML content to be returned to the browser. In .fwx files, scripts are differentiated from text and HTML tags by delimiters. A delimiter is a sequence of characters that marks the beginning or end of a block. FoxWeb by default uses the delimiters <% and %> to enclose FoxWeb code. If the FoxWeb code block starts with an equal sign then FoxWeb treats the block includes a single expression, which is evaluated and inserted in the HTML output. Blocks not starting with an equal sign are treated as regular VFP code. The following example shows a simple FoxWeb script that contains a FoxWeb expression: Sample Script : --------------------------------------- This page was served on <%=DATETIME()%>. ------------------------------------------------------------------------- This page was served on 12/18/99 8:43:10 PM. Including Multiple Procedures and Functions A FoxWeb script may contain multiple procedures and functions. These procedures can be called by other procedures, or directly by a browser by including the procedure name in the URL. The following code is a FoxWeb script called SysDate.fwx with three procedures and one function. The procedures are meant to be called directly by the browser. The function, called PageHeader is used by all three procedures to produce an HTML header: Sample Script : --------------------------------------- <%=PageHeader("Main Menu")%> <% CurrentHour = HOUR(DATETIME()) IF CurrentHour < 12 %>Good Morning!<% ELSE %>Hello!<% ENDIF %> show="" target="_BLANK">href="ShowTime@SysDate.fwx">Show System Time show="" target="_BLANK">href="ShowDate@SysDate.fwx">Show System Date <% RETURN PROCEDURE ShowDate %> <%=PageHeader("System Date")%> The Date is <%=DATE()%> Back <% RETURN PROCEDURE ShowTime %> <%=PageHeader("System Time")%> The Time is <%=TIME()%> Back <% RETURN FUNCTION PageHeader PARAMETERS PageTitle RETURN "" + ; " " + PageTitle + " " %> ------------------------------------------------------------------------- The first procedure, which has no PROCEDURE statement at the top displays the main menu for this sample application, and can be called by simply calling the fwx file itself. In order to call the other two procedures in the file (ShowDate and ShowTime), we need to include their names in the URL, as seen in the code of the main menu (href="ShowTime@SysDate.fwx">;). Adding Comments to Scripts FoxWeb scripts can contain two types of comments, HTML and VFP. HTML comments must start with . They can span several lines and may not be located in a FoxWeb code block. HTML comments are sent to the browser and can be seen by the user, using the browser's View Source function. VFP comments are the regular comments of the FoxPro language (both * and && comments are supported). VFP comments must be located in FoxWeb code blocks and, contrary to HTML comments, they are not sent to the browser. The following example contains both kinds of comments: PRG vs. FWX Files FoxWeb has the ability to call both FWX and PRG files. PRG files are regular FoxPro programs, which may only contain FoxWeb (VFP) code. You may not insert delimiters or mix free-flow HTML content with your FoxWeb code in PRG files. All output must be generated programmatically, using Response.Write or other FoxWeb functions. There is no difference in terms of performance between PRG and FWX files. In fact, FWX files are converted into temporary PRG files before they are compiled into FXP files the first time they are called (and whenever they are modified). Other than backward compatibility, there is almost no reason to use PRG files in your FoxWeb applications. An FWX file with a single code block enclosed by delimiters is exactly the same as a PRG file, containing the same code without the delimiters. As you will see in the Locating and Addressing Scripts topic, you must never use the PRG extension in URLs when calling PRG files. Depending on whether you utilize conventional or script-mapped URLs, you should either use no extension or the FWX extension (for uniformity you can make it a rule to always use the FWX extension, even when you are using conventional URLs). You may not mix PRG and FWX files with the same name in the same directory. FoxWeb will only run the newest of the two files, based on the file modification date. If you are not careful, you can overwrite an existing PRG file by creating and calling an FWX file with the same name in the same directory. FoxWeb uses the following algorithm in deciding which file to run, regardless of whether the extension specified in the URL was FWX or nothing: