Route Web Connection Scripts, Templates and Pages to a single Process Class

West Wind Web Connection supports a number of different 'frameworks' for generating HTML. There are two styles of MVC (Model View Controller) renderers and an ASP.NET like Forms based interface for creating rich FoxPro code based HTML pages.

These engines are available:

• Web Connection Scripts (wcs by default)
  HTML templates that compile into FoxPro PRG files and are executed as code

• Templates
  Simple templates that work well with embedded expressions and self contained code blocks that are evaluated on the fly (ie. no compilation).

• Web Control Framework Pages
  These are ASP.NET style pages that use an object based approach to describing controls on a page.

Both Scripts and Templates work for MVC style applications where you have controller code in a class method, and the template/script is the view that displays the model data you accumulated in the controller code to display in the script or template.

Web Control Framework pages are more complex, compiling HTML controls into component classes that are coordinated and rendered by the page framework.

Only one Default nPageScriptMode

When you set up a new Web Connection process class that process class can associate with a default nPageScriptMode:

• 1 - Template
• 2 - Web Control Framework
• 3 - Script

The default is 3 - Script.

The default determines what happens when you access a page like NonMethodPage.wwd for example, where there is no matching method in the Process class. If there is no NonMethodPage method in the class, Web Connection falls back to the default nPageScriptMode to decide what to do with the script. In this case, wwd will be passed to the default nPageScriptMode which is 3 - Script which compiles the script into a small PRG/FXP and it runs.

Handling more than one nPageScriptMode

So I just said that there's only one default, right? And that is so, but... you can actually tweak the behavior by explicitly setting the nPageScriptMode based on parsing rules in your code.

If I wanted to have multiple script maps for a single process method I might set up wwd, wwds, wwdx extensions for templates, scripts and pages respectively.

I then have to make sure I route all of these extensions in my MyServer::Process():

CASE lcExtension == "WWD" OR lcExtension == "WWDS" OR lcExtension == "WWDX"
    DO wwDemo with THIS

actually this is enough if SET EXACT OFF as it is by default:

CASE lcExtension = "WWD"
    DO wwDemo with THIS

this makes sure all requests with these extensions are routed to my process class.

In the process class I can then handle the extension routing in the OnProcessInit():

FUNCTION OnProcessInit()

* ... other init code

lcExt = UPPER(JUSTEXT(this.oRequest.GetPhysicalPath()))
THIS.nPageScriptMode = 3
DO CASE 
   CASE lcExt == "WWD"
      this.nPageScriptMode = 1
   CASE lcExt == "WWDS"
      this.nPageScriptMode = 3
   CASE lcExt == "WWDX"
      this.nPageScriptMode = 2
ENDCASE

Because OnProcessInit() fires early in the process pipeline you can change the page scriptmode which is used in wwProcess::RouteRequest() to find the right handler. Checked this out and it works great using a single process class to route requests for each extension to the appropriate handler.

And voila - you can now handle wwd pages as templates, wwds pages as scripts and wwdx pages as Web Control Framework pages.

You can make the logic more complex as well and look at other parts of the request. Perhaps extensionless URLs or query strings etc. - you have full access to the Request object to do as you please to figure out what gets routed where.

It's a cool little trick for your Web Connection applications.

this post created with Markdown Monster