Rick Strahl's Weblog
Rick Strahl's FoxPro and Web Connection Weblog
White Papers | Products | Message Board | News |

A Preview of Features for Web Connection 6.0

June 07, 2015 •

I've set some time aside to start working new functionality for Web Connection 6.0. I've been really on the fence on whether I wanted to go down this path due to the ever declining FoxPro market. However, there is still a fairly large contingency of developers out there using Web Connection and even a fair amount of users that are coming into Web Connection as new users. The existing version works fine and has most of the features that most developers need, but the truth is that a lot of the samples, documentation and content have gotten really dated. We do build Web apps differently these days and while Web Connection still works fine for all the development scenarios with the updates I've provided over the years, the demos and documentation really don't reflect that very well any more.

So for Web Connection 6.0 I've been planning a few things to make using Web Connection a bit easier. I still work with a lot of customers building Web Connection applications and there are a few things that I think will really improve the usability of the product. While I plan on adding some new features and revamp the default Wizards and configuration, I also want to ensure that there's minimal to no impact on existing applications. While I expect the new project experience and layout to be different, the core engine and functionality won't change much so that existing applications will continue to run just fine on the new version.

Planned Feature Enhancements

There are 4 key areas that I'm planning on addressing with Web Connection 6:

  • Simplified Project Configuration and Management (and documentation)
  • Improved Templating and Scripting
  • Improved support for Mobile Web development (REST Services and Mobile friendly default templates)
  • Overhaul the default templates for new projects and the samples

These are only 4 bullets, but they are actually quite significant in terms of work that needs to be done, especially the latter two, which are mostly redoing the existing examples, as well as reworking the documentation to match. Some of the work fo the third item has already been done in Version 5.70 and forward, but there are additional improvements to be done and integrated.

Let's look at each of these.

Improved Project Setup

One thing that I've heard over the years is that it's a pain to manage Web Connection projects. In the past I've built the library in such a way to make it as easy as possible to create a project and ensure that the code 'just runs' out of the box. The result was that Web Connection generates new projects into the install folder, along with any other projects. If you manage multiple projects this gets messy – it's hard to separate your actual project code from other projects and from the framework code.

So last week I built a new New Project Wizard that creates projects in a much more self contained fashion. When you create a new project with Web Connection now you create a new Project folder that contains both the Code, and Web Folders underneath the new project root. The code folder contains only your own code and Web Connection is referenced via SET PATH. The new Wizard generates the necessary pathing and a shortcut to make it easy to get set up properly so that your project just builds. This was tricky to get right, and in fact has been the reason I did not want to actually implement this in the past.

The New Project Wizard has been whittled down to 2 simple  pages now:



Gone are are most of the choices for file locations and IIS configurations beyond picking the site so this is much less intimidating for new users.

This is possible because with the new project structure we can create new projects with a known location and all of the paths for the Web site and configuration file locations can be determined based on the project path.

The default configuration settings are now also using relative paths for most paths, so that configurations are much more portable. In many cases you can just push up your project folder to a server and other than setting up the IIS ApplicationPool and Virtual directory the application should just work.

Here's what the project layout looks like:


There's a project root folder (DevDemo) and deploy and web folders. Deploy is the 'code' or 'binary' (or both) folder for your project – this is where your application starts from. The web folder holds all the Web content and that's what's mapped in IIS to the Web site or Virtual directory.

The deploy folder contains your server and process classes, the project file, the compiled EXE and INI configuration file. The project wizard also generates a config.fpw file that has paths pointing back to the Web Connection install folder (or whereever Console.exe was run from) and a desktop shortcut for the project was also created that points at that web.config file.There's also a SetPaths.prg which does the same thing if you just change path to the folder as a lot of you do.

Also notice that the temp path has now moved into the Deploy folder by default. This is a known application in this project – for the executable it's just ".\temp", for the Web app it's "~/../deploy/temp" – a relative location. Again if you move this app to the server with this same folder structure, things just work without reconfiguring paths in your config files.

Note that this is just a new default setup. Nothing has changed in the way you configure Web Connection itself meaning that if you still want to put your Web folder into inetpub/wwwroot you can do that as well. You can move the code folder, web folder – anything at all. You just have to manually adjust the configuration settings in IIS and your configuration files to match.

Better late than never right? :-)

Templating and Scripting Improvements

When I released Web Connection 5.50 a few years back, that release paid lip service to the fact that the Web Control framework that was introduced in Web Connection 5.0 didn't really take off. While there are a number of you that are using that framework heavily most developers are continuing to use the templating and scripting features. 5.50 introduced the wwHtmlHelpers set of helpers that provide a lot of the functionality that many of the Web Controls provide for the simpler scripting and templating applications.

For Version 6.0 I plan on adding a couple of important features to templates and scripts:

  • Integrated Partial Rendering
  • Support for Layout/Master Pages

If you've used any sort of server side MVC (Model/View/Controller) framework before you've probably noticed that Web Connection's ProcessClass/Script/Template mechanism essentially was an early MVC implementation. However, most modern MVC implementations support nested views in a variety of ways. Having an easy way to pull in nested content or Partials makes life a lot easier. Web Connection has always had support for this but the syntax for it was nasty and it's very difficult to discover.

Likewise there's the concept of 'Layout' pages that are sort of a master view container. Most applications have a 'base' layout into which other content is added. So you have a Layout page into which you render you actual page content. The page content then in turn can have Partials to render additional reusable components into the page.

In the last couple of days I implemented both Partials and Layout pages for both the template and script engines in Web Connection.

Here's how this will work.


Web Connection templates are typically rendered with Response.ExpandTemplate() or by using .wc pages through the default script map handler. Templates are basically evaluation only templates that are loaded and executed by parsing the document and replacing FoxPro code expressions and script blocks. Templates only support self-contained code blocks, but don't support structured code that mixes HTML and code.

The new Partial and Layout features fit well with templates however since these operations are basically just expressions calling out to other templates. Here's an example of a set of templates that can interact with each other:

<% Layout="~/LayoutPage.wc" %>

<h3>This is my rendered content</h3>
    Time is: <%= DateTime() %>
</p> <%= RenderPartial("~/PartialPage2.wc") %> <%= RenderPartial("~/PartialPage2.wc") %> </div>

RenderPartial() delegates out to another script page, which simply contains more script content just like this page. The partial page in turn can contain additionally nested content.

The syntax is:

<%= RenderPartial("~/PartialPage.wc") %>

and has to be used with this exact spacing and syntax in order to work properly. The ~/ denotes the root of the Site/Virtual so this expects a PartialPage.wc to exist at the root of the site. The ~\ syntax is required!

This content on this page is meant to be rendered into a Layout page. You'll notice that this page is really just an HTML fragment, not a full document. There's no <html> or <body> tag – that's meant to be provided by the layout page specified by this syntax:

<% Layout="~/LayoutPage.wc" %>

Again the ~/ is required and points at the root of the site/virtual.

The actual layout page in turn looks like this:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
    <h1>This is my LAYOUT PAGE Header</h1>

    <%= RenderContent() %>

    <hr />
    LAYOUT PAGE Footer

This page has the HTML header and it pulls in the  content from the previous page we looked at via:

<%= RenderContent() %>

Layout pages are great for creating a basic shell of a layout – that includes the HTML header and other content that ends up on just about every page of your application. It's great for pulling in css and scripts and base layout for pages.


Web Connection scripts are typically called using Response.ExpandScript() or by using scripts on disk with a .wcs extension. Scripts are parsed into full PRG based programs that are executed as compiled FoxPro code. Scripts support most of the same features that templates support, but additionally can also run structured statements that mix HTML and code. Because scripts are compiled FoxPro, a compilation step is required by Web Connection and it's not quite as straight forward updating script files if multiple instances are running and have the compiled FXP files locked.

The new Partial and Layout rendering in scripts uses the same syntax I showed with templates.

<% Layout="/wconnect/LayoutPage.wcs" %> 

<h3>This is my CONTENT PAGE</h3>
    Time is: <%= DateTime() %>
<% for x = 1 to 10 %>
    <h3>Partial Content below</h3> 
    <hr />
    <%= RenderPartial("~/PartialPage.wcs") %> 
<% endfor %> 

In this example a partial is rendered 10 times in a loop which demonstrates the structured mixing of code and HTML that you can't do in templates.

As in the template example, the layout page has to include a call to RenderContent() to force the content page that referenced the Layout page to be rendered.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
    <h1>This is my LAYOUT PAGE Header</h1>

    <%= RenderContent() %>

    <hr />
    LAYOUT PAGE Footer


Layout Sections

You can also create layout sections in the master that are 'filled' from the content page. A typical example for this is when you want to add scripts or css stylesheets to a page from the Content page. Or if you have some other area of the page that you want to fill with content from the content page. Essentially this let's you embed content outside of the content rendering area from the content page.

Start by setting up your layout page:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
    <%= RenderSection("headers") %>
    <h1>HEADER FROM LAYOUT PAGE</h1>    
    <%= RenderContent() %>    

    <hr />    
     <%= RenderSection("scripts") %>     

This designates two sections for headers and scripts. The string is a label of your choice – you can have as many section as you like.

In the content page you can then create sections that will essentially fill these sections in the layout page:

<% Layout="/wconnect/LayoutPage.wcs" %> 

<% section="headers" %>
     <title>My Content Page</title>
<link href="css/MyPage.css" rel
="stylesheet" /> <% endsection %> <div> <h3>This is my CONTENT PAGE</h3> <p> Time is: <%= DateTime() %> </p> <h3>Partial Content below (10x)</h3> <hr /> <% for x = 1 to 10 %> <%= RenderPartial("~/PartialPage.wcs") %> <% endfor %> <hr /> </div> <% section="scripts" %> <script src="bower_components/lodash/lodash.js"></script> <% endsection %>

You can also use script expressions (but not code blocks) inside of sections. Sections can fill parts of a document such as a user status widget perhaps that displays user login information. Lots of options here.

At this point sections only work in scripts, not templates. It took some extremely ugly recursive and generator style code to make this work, and I'm not sure at this time whether it'll be possible to make this work with the current template engine. But then again, if you are doing stuff complex enough to require sections and layout pages you probably should be using scripts anyway.

Finicky Tags

In order to keep the parsing overhead to a minimum when dealing with these new 'directive' tags, the tag names have to match exactly – including spacing inside of the tags. This allows quick searches for these tags in the page rather than traversing the document to find them which dramatically speeds up the performance. All of the new tags are not directly executed by FoxPro – the various expressions were chosen for easy to remember and logical names in order to make it easy to use them in the page. They are translated into actual executable script code when the page is parsed – they expand into something different. Sections in particular turn into some real ugly code with literal strings, but that's the price for this level of complexity. As before you'll be able to see the underlying code that makes the pages actually run in the codebehind PRG files that are generated.

Partials and Layout should make building complex apps quite a little less repetitive as you can do away with a lot of boiler plate code and simply put it into a Layout page.

Although you could do at least partials before, these new features standardize the behavior significantly and make it more transparent.

Improved support for REST/API Services and Mobile Web

Mobile applications are becoming more important by the day as more people are relying on mobile devices of various sizes to access their data and applications. Building mobile applications is quite different than building 'classic' Web applications that they need simpler user interfaces and handle display more effectively. As a result we've seen a big move towards client centric applications that use HTML/CSS and JavaScript to handle the user interface, using the server to serve static resources and server based services to feed data.

In the last releases of Web Connection (5.65 and later) there have been steady improvements to provide for that REST/API Service layer via the new wwRestProcess class that can facilitate consuming and serving of JSON data from your FoxPro business objects. There are a number of additional improvements that can be made here in terms of performance and simplifying the interface even more. This will be mostly an incremental change but it's an important piece in the overall Web Connection 6 package.

The other piece of that is the client side. This isn't directly related to Web Connection other than providing improved examples that demonstrate how to build these type of applications that use an all browser based client side user interface and that works well both on mobile devices as well as full sized applications. The Music Store sample was the start of that. Again some of the functionality it there already but it's part of the packaging for 6.0

Updated Samples And Default Templates

As mentioned at the beginning of this post, the main reason to consider all of this work is to make it easier to get started with and set up new projects that are ready to go. This is for my own work as I still work with a host of customers both to showcase specific functionality as well as creating actual new projects.

The goal is to build new templates that default to using Bootstrap for user interface layout. I plan on providing a default theme based on bootstrap that provides a basic customized bootstrap setup that can be easily customized (or go back to stock bootstrap if you choose).

This seems like a minor thing but there are a number issues related to this. All of the samples in Web Connection are based on old custom CSS that don't use any special CSS or other dependencies. While that worked in the old days, it's now to really look like crap and dated. This involves going through all the existing samples, all the existing admin features etc. and starter templates. This will take some time unfortunately and most of this is tedious boring work :-)

Along the same lines a lot of the simple feature samples in Web Connection need to be updated – some just need a visual refresh, others need a complete logic rebuild to work the way you'd do things today. Some of these samples are nearly 20 years old, so yes there's some room for improvement I suppose.

Likewise the Web Control Framework functionality uses all the old styling, so I'm not sure that I will be updating these controls to use the new layouts. THere's too much baggage there to make that work – that might be a 6.1 feature.

Dropping Visual FoxPro 8 Support

One thing that has made maintenance of Web Connection more problematic over the years is support for Visual FoxPro 8. With version 6 I will be dropping support for VFP8. There's no good reason for anybody to be running VFP8 these days, given that VFP8 and VFP9 have very, very little in the way of feature differences. This was not the case for earlier versions of 7 and 6, but those haven't been supported for some time.

I know some of you will howl at this (I still get frequent requests for 'does this tool work with VFP 6?'). There's no excuse to be running anything but VFP 9 if you are running FoxPro applications. Maintaining VFP 8 support has been an issue as it requires extra testing, extra files to distribute to keep in sync and having to remember what we can and can't use in the latest versions of our tools.

Other Odds and Ends

There are a few other things that need attention as well. The authentication features in Web Connection are reasonably functional, but hooking them up currently is both badly documented and could be easier by providing a few additional hooks. It also would be nice to set up a default login page template that is easy to customize as part of a new application – this way you can simply modify a Web page to get the look that you want without having to override a bunch of process class methods as you have to do now to essentially do the same thing.

The various Wizards also will need some updating to reflect the changes to the new templates. For the most part the updates will be minor except for the new Process Wizard which will also need a similar overhaul as the new project Wizard does.

What else?

If you're using Web Connection, what's on your wishlist? What features do you want to see that I've missed that are within the realm of the core framework? I know there are tons of request to build this or that vertical functionality but I can tell that's not going to happen from me – that's what you guys can build ontop of Web Connection :-) But if you have core framework features or utilities that you think would make your life easier, I'd love to hear about it.

Posted in: Web Connection

Feedback for this Weblog Entry

re: A Preview of Features for Web Connection 6.0

June 07, 2015

Dear Rick, I am enthusiast about a new version of Web Connection! I am very grateful to you because I can still work with Visual FoxPro just thanks to your fantastic framework. My projects are updated to 5.62, I stopped to follow your upgrades when I ecountered compatibility problems, expecially with wwWebTabControl object. So about new features I would like to find in WC 6:

  • compatibility with every 5.x layout feature
  • ability to develop applications for mobile devices
  • possibility to develop liquid layouts

Many thanks on advance ??

re: A Preview of Features for Web Connection 6.0

Rick Strahl
June 09, 2015

I can tell you right of that backwards compatibility - especially for client side features is not something that can be maintained. This update will bring some breaking changes especially for Web Control Framework as I am rebuilding the base CSS code.

This release is going to be about fixing and normalizing a bunch of things that were done in the past for reasons of backwards compatibility. This release is meant to put things into shape so the product can go on without being completely obsolete (even if FoxPro is going that way).

Also as I mentioned there will not be much change in the Web COntrol Framework. Focus will be on client side integration features (SPA applications, and updates for the Template/Scripting engines). WCF will get the CSS UI updates but not much beyond that.

re: A Preview of Features for Web Connection 6.0

June 11, 2015

Thanks Rick... I'll be using wconnect for as long as it's out there.. Will also pay for New Versions... I've been using Meter.js lately.. it's pretty cool.. uses mongo as database.. however any developers new to Meteor dont like the fact that they have to use mongo "nosql" so SQL support is on the way... I thing someone is building a postgres driver.. would be cool to have a wconnect driver..

© Rick Strahl, West Wind Technologies, 2003 - 2024