Making Web pages with VFP (i.)

It's written in front.

This article should have been written 3 years ago, when Visual FoxPro 6 just launched, one of its selling points: working with ASP to act as a Web Server. In general, the domestic understanding of technology, the domestic demand for technology, and the domestic acceptance of technology are clearly behind the foreign--today, when it is time to discuss Web Service, I would like to spend some time with you to explore the Web Server.

As for the difference between Web Server and Web Service, the BOE will have a thematic discussion.

I have never written the ASP code, this article power as the stone of the jade ...

Origin

A few days ago, Boby gave me a qxf to write the FoxWeb application, very good. FoxWeb is a third party product of Visual FoxPro. I was thinking, can I use pure Visual FoxPro to achieve the same function?

Of course, the core technology of Web Server technology and FOXWEB application is the COM component written by Visual FoxPro, only as a third-party product FoxWeb has added some other functions, it is heard that provides a script language that functions like ASP, its syntax habit and F Ox is about the same.

Here, we will not use any Third-party products to implement a simple Web Server. Now, let's get started!

The overall architecture

Basic WEB Page

You should know that the most basic page (the pure static type, www.boeworks.com belongs to this category) is how to be displayed in your browser, you should also know the basic principle of the browser.

The client browser sends a Web page request to the Web server, and then the Web server processes the request and sends the HTML code of the Web page back through the Internet to the client browser that sent the request, parsing the HTML code by the browser, and finally displaying it. The HTML code here can, of course, include some other client-supported code, such as CSS, DHTML, XML, or even Jscrip, Vbscrip, which, in short, are executed or parsed in the client browser like HTML code.

In general, a basic Web page is a Web server that sends the HTML code back to the client browser "directly" after it receives the request. The system architecture diagram for this pattern is this:

Dynamic page on server side

This simple page-handling pattern does not solve our needs because the WEB server simply returns the out-of-the-box HTML code back to the client browser, which is very "dull". For example, in a forum site (like www.myf1.net or http://www.foxcn.com), is it necessary for every new post to be a Web site maintainer to make a page again? This is obviously impossible!

In order to create a flexible intervention page between a WEB server accepting a client's browser to send a request and a return page, many approaches have been proposed: CGI, ISAPI, ASP, ASP.net, PHP, JSP ... Their common feature is to intervene in the generation of returned Web pages, which can produce pages of different content based on the specifics of the Web server (often based on the database), which is called a dynamic page. Just said Www.myf1.net is based on ASP (but not the use of plug-in components), and http://www.foxcn.com is based on CGI technology.

From the MS Perspective, support for Dynamic Web pages is implemented primarily through CGI, ISAPI, ASP, and ASP.net, both of which run on the Internet Information Server (IIS) of MS WEB server products.

Well, look back and see how our Visual FoxPro is involved in these applications. Visual FoxPro fully supports ISAPI, ASP, asp.net,visual FoxPro can provide components for them. When it comes to components, of course, it refers to the COM components developed by Visual FoxPro.

Today's topic does not cover the combination of ISAPI and asp.net with the visual FoxPro COM component (BOE has a planned thematic discussion and a combination of asp.net applications), where we focus on the ASP and visual FoxPro developed C A federated application of the OM component.

When the ASP leaves the COM component

First of all, we use our own Fox experience to think about: Visual FoxPro written by COM can generally provide some of the functions? My answer is the processing of the database, which includes Visual FoxPro Local data and various types of remote data (data from Access, SQL Server). After confirming this point, let us see if there are any morphemes in the ASP that deal with the database: Yes, it is the famous ADO. ADO belongs to ASP's built-in (Built in) component, and similar to session, application and other components.

As far as I know, many people now use ADO in Visual FoxPro, so is it superfluous to use visual FoxPro to develop COM for ASP calls? I see, not necessarily, for the following reasons:

First. In ASP, the driver runs a scripting language (usually Vbscrip). Since it is a scripting language, it is doomed to the ASP program is interpreted to execute, inefficient! While Visual FoxPro is the language of compilation and execution, the long history of Fox has proved its speed of processing data and processing strings, and placing a large number of processing databases and processing strings into the COM components written by visual FoxPro will undoubtedly improve the efficiency of ASP. Someone tested, using the Visual FoxPro COM later than the pure ASP program speed to improve several times even dozens of times times!

Second. If you've seen the ASP code written by someone else, you may have a headache-a professional programmer will be very unaccustomed to the HTML and VB scripts in ASP. So, people often complain: the page changes, the ASP code on the messy mess ... If we split the relevant code into COM components, using Visual FoxPro object-oriented and process-oriented advantages, it makes the entire code cleaner and easier to maintain.

Third. In some large applications, it is possible to consider the load balancing and distributing transactions of the server, which cannot be solved by simply ASP. COM, which is written by Visual FoxPro, supports MS COM +, which solves the challenges of load balancing and distributed transactions through COM +.

Fourth. This is the most affordable point. With COM, we can make traditional Visual FoxPro programmers become a part of the WEB solution, and do not need to learn more new technology, at least for data processing, we are "expert".

ASP's architecture for invoking COM written by Visual FoxPro

This is the "ASP called the Visual FoxPro written COM" architecture diagram, here I explain:

Like the basic WEB page, the client browser sends the request to the Web server, the Web server receives the request, executes the ASP script, generates the HTML code to return to the client browser that sent the request, and the client browser parses the HTML code and displays the Web page. When executing an ASP script, you can invoke various COM components as needed, and a generic COM component will return some data to help the ASP generate HTML code. The COM components here can be written by various development tools, including, of course, by Visual FoxPro. If you are a COM component written by Visual FoxPro, you must have relevant visual FoxPro Run-time support at run time. For example, in Visual FoxPro 7, the Run-time file that compiles to COM within the multithreaded process is vfp7t.dl.

In the above picture, you may be able to do the same for ASP. DLL will have questions, this is actually the ASP's run-time files, ASP's functions are derived from it!

Updating COM components

In general, COM components run in the memory space of IIS (in-process components). When IIS is started (often when it is powered on), the first time that COM builds is invoked, the COM build runs in the memory of IIS (so the first call is particularly slow), and then we cannot recompile and update the COM component. Before, you often see a suggestion to restart your computer, which poses a lot of trouble debugging COM components. Here, I introduce an easy way:

Executing in the Command line window: iisreset

Its role is to attempt to shut down and restart IIS so that the COM component being run is freed. In this way, you can easily recompile, update the COM components!