For the 70-155 Certification Test:
Interact with Visual FoxPro from a Web page. Considerations include:
Fox ISAPI, DHTML, ASP, and XML.
If Fox ISAPI is a Server Sample, would it be good/bad/indifferent to use it and a COMComponent for a small (and growing) intranet app? -- Chad Bourque
The problem with Foxisapi has always been configuration. You want to be able to get the web app up easily and to easily make changes with minimal downtime. I'm not sure Foxisapi fills the bill. Another consideration is support: foxisapi does not appear to have any. And devs with good experience in it are few and far between. Also, there is no more development of foxisapi by MS or anyone.
And although some of the included notes say that you should be able to run Foxisapi as an MTDLL, I've never been able to run it this way or seen anyone else do this either. What that means is you'll be limited to "simulating" multi-threaded servers by running multiple EXE servers. This, more than likely, will lead to serious scalability issues (at least for really busy servers) and/or deployment issues.
The best solution IMO is just to call VFP mtdll servers from ASP.NET or ASP. Examples of open source projects doing this are Fox Trails and ActiveVFP. This gives you some pretty good speed and scalability and is fairly easy to setup, change, administer.
more to come...
Let's think about the various ways that a web page client/user interface can interact with Visual FoxPro data and/or business-logic components.
Two of the considerations listed above involve server-side-only technologies: Fox ISAPI and ASP (Active Server Pages), where all interaction with Visual Foxpro happens on the back end, with an HTML result returned to the client, perhaps including some client-side script (Java Script or Vb Script).
The other two considerations, DHTML and XML, also involve server-side interaction with Visual Foxpro via Fox ISAPI or ASP, but also may involve considerably more client-side processing in manipulating the data.
In all likelihood, you will use some combination of the above in just about every web project, but with Fox ISAPI and ASP being mutually exclusive of each other.
Fox ISAPI and Visual Foxpro
Be sure to check the excellent information at the Fox ISAPI wiki topic. In a nutshell, here's what happens: A Web browser navigates to a web page by requesting a URL similar to this:
http://www.someplace.com/foxisapi.dll/foxis.exployee.startup (an example included with VFP).
This tells the Web Server to pass off a request to foxisapi.dll (running in-process in the Web Server), which will grab the additional parameters from the URL and process them, returning HTML as the result, which the Web Server sends back to the Web Browser.
Fox ISAPI processes the request in this case by instantiating the "employee" OLEPUBLIC class in the "foxis" VFP COM automation server (an out-of-process .exe) and then running its "startup" method. Inside the employee class is VFP code that opens tables, runs a query, builds HTML, and returns the result.
Active Server Pages and Visual Foxpro
A Web Browser client can interact with Visual Foxpro via ASP in several ways. Vb Script or Java Script embedded in the ASP page source runs on the server and does one or more of the following:
- Opens an ADO connection to VFP data through ODBC and creates a recordset, using information in it to create the HTML to return.
- Instantiates a VFP COM object and calls methods that return HTML and/or queries properties to get data for creating HTML. The COM object built from your VFP code could be an out-of-process .EXE or an in-process .DLL, perhaps running under Microsoft Transaction Server (MTS).
- NOTE: In the second example, the data may be coming from VFP native tables, or from SQL Server or other datasources being queried by VFP via a RemoteView or SQL Pass - Through.
- The HTML or data returned by either method above will be "merged" with static HTML code that is in the ASP page to make a complete, but dynamically-created web page.
- Any more ideas for ASP, anyone?
XML and Visual Foxpro
XML holds much promise as a universal data-transfer technology. VFP can create XML (which is just specially structured text similar to HTML) by simply creating a text string mixing XML tags, text, and data from tables or from VFP functions. This string can then be returned to the calling routine, where it can be parsed, copied to a text file, or passed on to another routine. (Parsed or passed!).
In recent InternetExplorer versions, XML returned to the Web Browser as part of the HTML page can establish a "data island" in the page that can be displayed and manipulated by DHTML.
Get Rick Strahl's free wwXML download from www.west-wind.com for an elegant and fast implementation of XML conversion to and from VFP cursors (remember... can be from local Fox tables, local or remote views, or SQL Pass - Through) and ADO recordsets.
We'll be seeing a lot more of XML in the future, so now is the time to get acquainted with it.
Blah, blah, blah... examples, anyone?
DHTML and Visual Foxpro
Dynamic HTML is, well, dynamic. It can respond to user interface actions or events in the Web Browser and change the display of HTML and data accordingly.
That's all I know so far. More, anyone, with simple example?
more to come...
Contributors: David Stevenson
Category Exam 70-155 Example
( Topic last updated: 2008.02.20 07:55:01 AM )