Step 2 - Testing the installation
Once the project's been created you can start running the application right away. The first thing you need to do is start the Web Connection server. The server is a FoxPro program you can run.
There are two ways to launch the Web Connection Server:
- Directly starting with
New projects get a new
Launch.prg that is meant to make it easy to start your application and bring up a Web Browser on the default page.
To use with IIS it run
DO Launch *** Or maybe easier: Launch()
Or you can specifically specify what server to use:
Behind the scenes this does the following:
- Launches the FoxPro Server with
- If running IIS Express launches IIS Express in the Web Folder on port
- Navigates to
- You can optionally change the port in the generated
Once the browser is up and running you can also run only the server without launching a server or browser:
which launches just the FoxPro server and the configuration without launching the Web Server or Browser.
If you rather do all this manually, or once you've launched the application and you're making changes, you can also directly load the Web Connection server without all the other configuration and startup options. To do this:
*** Raw launch DO webDemoMain.prg *** Using Launch to just start the Server - loads environment Launch("NONE") && or "SERVER"
Each new project creates a
<projectName>Main.prg which is the startup for the FoxPro Web Connection server, that you can run. If you compile the project this file is also the main entry point for the application in which case you can just run
do <projectName>.exe (
This launches the Web Connection server - which is just a FoxPro application. You're now ready to respond to requests assuming the server is configured correctly.
Here's what you should see:
Now switch over to the Web browser default page that was opened for you and hit the
Hello World Test Page link (http://localhost/webdemo):
The Hello World request is nothing more than a ping to ensure that the server application is working and serving requests:
And voila, you have just fired your first Web Connection request.
Let's take a brief look at what's actually happening in this simple request. At the core the New Project Wizard created two PRG files that make up the core of your Web Connection application:
This is the server start-up file, that holds a subclass of the wwServer class. This code contains server bootstrapping and server configuration code that let's customize how Web connection runs and what libraries it should load and so on. You typically set configuration settings here when you start a project, and then only occasionally add some small tweaks to this PRG file. This is the PRG you run to start the server.
This is the actual request handler class where your Web application code is actually fired. This PRG holds a class and each public method of that class is a Web endpoint that responds to Web requests. You can implement these methods and write code in response to the Web request. You can use the
Responseobjects to capture user input and return HTTP output.
The actual code that executs and returns the Test Page output is very simple as you might expect. It's a method in the WebProcess class and it looks like this:
FUNCTION TestPage() THIS.StandardPage("Hello World from the WebProcess process",; "<p>If you got here, then your Web Connection Server is working." + ; "<br />You've been served by FoxPro and Web Connection." +; "<p>Server Time: <b>" + TIME()+ "</b></p>") ENDFUNC * EOF WebProcess::TestPage
StandardPage is a helper method that creates a self contained HTML page based on a default template. You only pass in some header text and an HTML body and it will render the page for you, using the formatted template (which you can modify). To make a change write out some dynamic value using FoxPro.
Maybe add the FoxPro
Version() string after the time value for example.
wwProcess::StandardPage is a high level method of the wwProcess class which is the base handler class upon which your class is based. But StandarPage is just one of many ways to render output. At the lowest level there's the Response object which lets you render raw strings into the HTTP output stream at a low level.
To demonstrate, we could rewrite the method completely using raw code:
FUNCTION TestPage TEXT TO lcHtml TextMerge NOSHOW <html> <head> </head> <body> <h1>Hello World from FoxPro</h1> <hr/> Hello world from FoxPro. Time is: << TIME() >> <hr/> <div>FoxPro version: <%= Version() %> </body> </html ENDTEXT *** Not necessary here - for demonstration only Response.ContentType = "text/html" Response.Write(lcHtml)
If you want to try it, make the code change and simply re-run
DO WebDemoMain and you should see your change immediately. You can do all the things you do in FoxPro code: Make changes, access databases, call UDF() etc. You can also set break points and step your code as Web requests come in.
This is as low level as it gets and it gives you total control over how to send output. There are a number of other ways to generate output and we'll cover those in the next steps.
Note that you don't have to write the entire content out in one go either - you can use multipe Response.Write() commands:
FUNCTION TestPage Response.Write("<html><body>") Response.Write("<h1>Hello World " + Time() + "</h1>") Response.Write("<body></html>")
which is perfectly valid as well. We'll look at other more high level approaches to generating HTML output later in this tutorial.
If you look back at the server window in FoxPro, you should see a request be written out to the server window as it's fired. The request shows the name of the script that executes and how long it took to process in seconds.
You can also click on the Status button to bring up the Web Connection Status form which shows some basic configuration setting for the server.
The settings in this window should look familar - the settings match the settings I made in the first step when running the New Project Wizard. The most important values are the Startup directory which should be the current directory, the temp directory and the template setting, which are used for the file based messaging that we are currently using to run our server.
You can change and save the values for these settings here or in a configuration file -
WebDemo.ini - that hold these values.
Note also that there's a Save Request Files checkbox. When checked this tells Web Connection to save the request and response data from the last request, which is a useful debugging tool if you would like to see EXACTLY what IIS sent you and what exact output was generated.
This allows you to see what data is available on input, which is useful if you're looking for specific Web server provided values. It's a useful debugging tool.
The Display Request Files feature is useful during debugging but make sure you turn it off at runtime as it can slow down request processing as it writes out extra content to disk and causes request blocking/queuing.
Comment or report problem with topic