Over recent months I've seen a number of questions on the message board regarding whether to use the Web Control Framework in Web Connection or to use the more traditional raw code approach of classic Web Connection. I thought I'd address a few of these issues and compare scenarios in this blog post in no particular order, since I think there's still a lot of confusion about what the Web Control Framework (WCF) is and isn't.
Does Web Connection 5.0 require .NET?
The first question I see over and over again is whether Web Connection 5.0 and the WCF requires .NET. The answer is plain and simple: No. The WCF runs is implemented in pure FoxPro code and all code you write is pure FoxPro code. Web Connection never loads the .NET runtime in your FoxPro server code (unless you loaded explicitly in your code).
I suspect the association with .NET comes through the videos and the Visual Studio 2005/2008 designer support they demonstrate. We optionally support using the Visual Studio designer to layout Web Control Framework pages and the designer support includes a set of .NET controls to provide the design time experience in Visual Studio and an Add-in that provides bringing up FoxPro code easily from within the Visual Studio designer. Visual Studio is optional. The page markup used in the WCF is pure text and any text editor can be used to design layouts. However, without Visual Studio you cannot preview your layout unless you run the pages and you don't get the benefit the property sheet and Intellisense which greatly help in discovering what features are available on the built-in controls.
To reiterate – your running applications don't require .NET to run Web Connection 5.0.
A quick Review of Web Control Framework Basic Concepts
The Web Control Framework (WCF) offers a host of new features including an ASP.NET like page model that allows you to easily compose complex pages and have the framework manage page content for you. Because the control framework manages the rendering of controls on the page for the most part, your code generally doesn't have to deal with updating various page components and managing their state explcitly as pages 'remember' this state on their own.
To put this in perspective with 'classic' Web Connection imagine you have a page that includes several input areas on a single page. With classic Web Connection you'd have to ensure that all data is updated on each of these input areas by explicitly assigning and if necesary converting data for display purposes. When one of the entry areas would submit you'd have to specifically test for that submission – typically by checking for a specific button having been pressed ( Request.IsFormVar("btnEmailUs") ) and then using some sort of switching logic like a CASE statement to handle each of the actions on the page. That alone adds up to a fair bit of code, but now imagine on top of this that you also need to set a variety of attributes on these form areas – enable/disable entry controls or entire areas, and it was quite easy to end up with a large amount of code and template (if using templates for rendering) logic to make the UI behave.
The Web Control framework removes the need for many of these types of behaviors because you have a Page and Control model that allows addressing of components in the page. Most of this can be done in the context of code without having to worry about HTML semantics.
For example, disabling a control is as easy as setting
this.txtName.Enabled = .F.
in code without having to generate HTML like this in a classic template:
<input type="txtName" <%= iif(llNameEnabled,"Enabled","") %> />
And that's not even taking into account more complex controls like checkboxes and radio buttons which use funky logic to determine their value state.
Even better in the WCF if you want to persist this state automatically without having to set it on each page post back you can simply call:
and from then on the control property is automatically set to its last value on the next post operation. All property settings can be made either in code as above or declaratively in the page markup.
And the markup is the key. For example the wwWebDatepicker control can be defined like this in markup:
<ww:wwWebDatePicker runat="server" id="txtDateIn"
The HTML text representation allows setting any of the control properties in the markup declaratively, and when optionally using Visual Studio you get full designer support for the controls so you can visually arrange them.
The key for developers though is you can manipulate these markup generated controls in FoxPro page code in the page's code behind that is running pure FoxPro code. For example if I add a button with a Click event handler that fires this code to update the date picker.
So you can have a button in markup like this:
<ww:wwWebButton runat="server" id="btnSetNow"
Text="Now" Click="btnSetNow_Click" />
Which when clicked fires into server FoxPro page code like this:
this.txtDateIn.SelectedDate = DATETIME()
Obviously this is a very simple scenario, but it demonstrates that you can access any of the controls on the page in your FoxPro code. Unlike templates and scripts which were more like a static snapshot of the page state when rendering occurs, WCF pages are very dynamic with live objects that you can reference and manipulate both in markup and via FoxPro code on the server.
The combination of designer support in Visual Studio, declarative markup, easy code based access to control, event routing and complex encapsulated rendering of the controls make it considerably easier to use Web Control Framework pages to build anything but the most trivial interfaces.
There's of course much more to what the Web Control Framework can do for your page logic, but these few simple features alone make it much easier to create complex page layouts quickly and write logic to interact with that page layout the latter of which was simply not possible before. Once rendered classic pages were done. You had to render top down – out of sequence access was very difficult to deal with. The Web Control framework handles rendering for you so you can get your page state set up in code by manipulating control properties at any point. Order no longer matters – you can change a header element after you've changed the footer for example. Controlled rendering and access to any control on the page make it easy to manipulate page content easily.
Can I run classic Web Connection Process Methods?
One thing to understand about Web Connection 5.0 is that it supports both the raw code and templating approach as well as the new Web Control Framework. In fact, based on several messages on the message board recently, Web Connection and even mix and match both in the context of a single wwProcess class.
As in previous versions of Web Connection the wwProcess class and your subclassed implementations of it still work as they always have even when you are set up for running the Web Control Framework. wwProcess now as in previous versions FIRST routes to your wwProcess class methods if they exist.
So if you want to implement a page using raw code or using Response.ExpandTemplate() even in an application set up for the Web Control Framework you can do that. Assuming you have a .wcScript extension set up in your application you can have a method called HelloWorld in your process class, which will get called with Helloworld.wcScript. If you then have a TestPage.wcScript Web Control Framework page on disk the script page will execute instead.
The routing logic first looks for a method that matches the URL script name, and if that's not found goes out to disk and tries to find the script page to execute using the Web Control Framewokr.
What this means is that you can easily mix and match both new style Web Control Framework pages and old style raw code or templating approaches and so can gradually add support the new functionality to existing applications.
What's not to like about the Web Control Framework?
The Web Control Framework is new and it's very different from classic Web Connection code and I think uptake from existing developers has been relatively slow. That's understandable: There's an initial learning curve, especially if you are used to template or pure code based development and when first confronted with this new object model you realize you'll have to know a little bit about the available controls and properties available on each.
I think the short learning curve is well worth the effort because it can drastically improve your productivity and maybe even more so opens up whole new vistas of what you can accomplish with a Web interface that was just too tedious to do with template code. This is especially true if you use Visual Studio, which goes a long way to help you discover what controls and properties on those controls are available.
But there are some downsides to consider with the Web Control Framework. The most important one is that it is more resource intensive than raw code or templates. Request processing involves creation of lots of objects in memory and this has an effect both on memory usage and performance. Compared to classic applications Web Control pages will likely be slower, although a lot of that overhead can be made up with new faster and faster hardware, given that we're talking about code execution here.
Some people also have expressed worries about the Web Control framework not giving you full control over HTML markup. While it's true that the framework handles HTML rendering as part of the controls it provides and so controls what gets output for each control, most of the controls provide a rich member interface to finely tune the output generated.
And if all else fails you can still use Web Control pages and embed your own HTML into the page. The pages are effectively templates as well and you can certainly place any static HTML (or code generated HTML via <%= %> tags or the wwWebLiteral control) into the page. In other words you're not losing anything over what templates could in classic Web Connection. If you want the control to create manually optimized HTML you can still do this!!!
Finally the WCF allows you as the developer to create your own controls that DO EXACTLY WHAT YOU WANT. The same mechanism we use to build the framework controls is available to you as the developer. Again this opens up lots of opportunities for customization and reusability that simply weren't available before.
You can mix WCF and Process Methods!
One key thing to remember too is that if you have a request that requires the utmost performance because it's very frequently accessed or because it generates a huge amount of data, you can always create a single method in your process class that handles that particular request. The rest of your application can run with WCF pages but a few requests that need to be maximized for performance can be run as template or raw code. Process methods also work best for non-visual output, like image retrieval, XML generation or RSS Feed generation. While these things can also be done with WCF pages, there is usually no benefit in doing so and Process methods will work just fine for these 'transactional' operations and provide better performance.
Page Management and Deployment
Another somewhat complex process is management of WCF code behind pages. Because each page creates a PRG file and class that is dynamically invoked, WCF pages have to be manually added into a FoxPro project. It's easy to forget a page actually and find out on a live site that you are missing a page. Been there done that. There are actually several page deployment options you can choose which include embedding the pages into a project or distributing PRG/FXP files with your application.
The key thing to remember is that Web Connection compiles WCF pages into code entirely so each page – static text, controls and your code – end up in classes. This means modifying markup or code after compilation is not directly possible in a live environment. The smallest change in HTML requires a recompilation of at least that page or in the case of project embedded pages the entire project.
This is definitely a change from classic Web Connection operation where templates could easily be updated without any sort of code updates. However, I think this can actually be seen as advantageous – it can be rather liberating to have all code and markup compiled into a single executable that can be updated at once. One advantage of this approach is that you don't have to hunt down the script pages that have changed on the server – instead you can make your changes in development, compile and upload to the server and you're done.
WCF pages must still exist on disk in order for IIS and Web Connection to be able to find them, but in precompiled mode, Web Connection doesn't actually read these files so the content in them is actually irrelevant. As changes are made to markup the server page don't have to be updated.
Web Connection 5.0 is a flexible framework and you have choices of how you can build your Web Applications. We provide functionality to do raw low level Http output via process methods and raw Response.Write() code, mid level templating and scripting through Response.ExpandTemplate() and Response.ExpandScript() and we provide the high level Web Control Framework. The base framework is used for all of these higher level implementations and the design is meant on purpose to make it easy to build applications in the way that you feel comfortable.
All that being said I do believe that for HTML based front ends the Web Control Framework is easily the most powerful and productive approach for creating HTML interfaces. There's a learning curve yes, but a few hours up front will probably save you a few hours on the first complex form you create. And remember you can always fall back to the raw process method code approach if necessary or mix and match with existing applications that use this approach.
If you are a Web Connection user and you're on the fence about the Web Control Framework I would encourage you to check it out.