FoxWeb 4 maintains 100% compatibility with scripts written for FoxWeb 2 and 3. As a result, you should be able to install this version over existing FoxWeb 2 installations without any adverse effects on your site. As always, we recommend that you test all new versions on a development/test server before deploying them to your production environment.
Starting with version 2, FoxWeb introduced a lot of new features that revolutionized how FoxWeb applications are written. Although these features make it much easier to create powerful sites, the new programming interface can at first be somewhat overwhelming to long time users. Moreover, some developers will not want to invest the time and effort involved into upgrading their existing scripts to take advantage of FoxWeb's new objects. In order to accommodate everybody's needs, FoxWeb 4 maintains compatibility with the FoxWeb 1 API. As long as the 1.x Compatibility configuration option is enabled, applications written for previous versions will run without any modifications. Such applications can still take advantage of the much improved scalability and management features of FoxWeb 4.
Even though you can still write applications with the old API, eventually you will invariably want to start taking advantage of the new objects, which make it much easier to read user input, create output, maintain session information, and add authentication. You will also want to take advantage of the new FWX scripting feature. The rest of this topic is divided into the various tasks performed by FoxWeb scripts, and it lists the old method of performing these tasks, compared with the new method.
CGI and ISAPI requests are accompanied with two types of information: Server variables and POST fields. Server variables are a collection of values that provide information included in HTTP headers, such as Cookie information and the Query String. POST fields are the values submitted by users as part of HTML forms. FoxWeb 1 exposed the various server variables as properties of the CGI object. Form fields, on the other hand were accessed via the FormField and TotFields functions, as well as the CgiFields array.
FoxWeb 4 consolidates all these API elements under the Request Object. Not only does this object provide all the functionality formerly covered by the above elements, but it also makes it much easier to decode certain compound variables, such as the Cookie server variable and the Query String. The ServerVariables, ServerVariablesCount and ServerVariablesArray methods replace the CGI object. The Form, FormCount and FormArray methods are replacements for the FormField, TotFields and CgiFields elements respectively.
In addition, the Request object includes the GetCookie, CookieCount and CookieArray methods, which make it much easier to read individual cookies, and the QueryString, QueryStringCount and QueryStringArray methods, which help decoding individual Query String fields.
FoxWeb 1 scripts returned output content to the browser by storing it in the html_out variable. HTTP headers, such as the content type, cookies and redirection directives had to be stored manually in html_out along with the rest of the content. The MergeTxt function made it easier to return HTML content by providing a text merge function, but was somewhat limited because it only supported VFP expressions. Regular commands such as conditional statements or FOR/NEXT, DO/WHILE and SCAN/ENCSCAN loops were not allowed.
FoxWeb 4 does away with the html_out variable, and instead provides a much more powerful infrastructure for returning content to the browser. The new FWX scripting functionality replaces MergeTxt and allows the mixing of FoxWeb script code and HTML content. In addition, the Response object makes the construction of HTTP headers a lot easier, with the Redirect, SetCookie, DelCookie and AddHeader methods, as well as the CacheControl, Charset, ContentType, Expires and ExpiresAbsolute properties.
Previous versions of FoxWeb encouraged the use of absolute URLs in links included in FoxWeb-generated output, whether they were pointing to other FoxWeb scripts or static files. The version of ContactMine included with FoxWeb 1 even used a function called MakeURL to construct such links. Even though absolute links will work fine in FoxWeb 4, they are not recommended any more, because they make it difficult to create portable code. You should use the techniques described in the Including Links in FoxWeb Script Output topic instead.
For security reasons FoxWeb 4 does not support the use of UNC paths in the URL and requires that you enable the Full Paths in URLs setting in order to even allow you to directly refer to scripts outside the FoxWeb Program Root and its subdirectories. It is recommended that you keep this option disabled. If you want to call scripts on a separate location (local or remote), you can do so by modifying the value of the Request.PathInfo property.
FoxWeb 1 included the external program passcook.prg as a means of password protecting scripts. FoxWeb 4 provides native protection via the Auth object. This object has similar functionality to passcook.prg, but it is easier to use, better integrated with FoxWeb, and has more features.
For the sake of ASP compatibility, the UrlEncode function has been replaced with the Server.UrlEncode method. Also, later versions of VFP provide the functions FILETOSTR and STRTOFILE, so the functions ReadFile and WriteFile are not needed any more.
Redirecting incoming requests by changing the value of CGI.LogicalPath is not supported any more. Use the Request.PathInfo property instead.