Weblog Home
Markdown Monster
Html Help Builder
West Wind WebSurge
Anti-Trust MusicShould you upgrade to Web Connection 5.x?
September 09, 2007 •
When Web Connection 5.0 released last year the primary focus of the new version has been a new Web Control Framework which is an ASP.NET like framework built in pure FoxPro code. Over the last week several people have contacted me with requests for updates and questions on whether they actually need Web Connection 5.0. In the words of one customer: “I don’t do much with .NET”. So apparently there’s be some confusion about what Web Connection 5.0 offers and what it isn’t – namely anything that has to do with .NET in any way.
So first off let’s get this out: Web Connection 5.0 has no dependencies on .NET for executing code except for one optional component which I’ll discuss later. I think some of the confusion may be because the demos and some of the screen shots show Visual Studio and well, if you’re using Visual Studio you must be using .NET, right? This is actually not so.
All code that you write with Web Connection is written as plain FoxPro code using anything that FoxPro provides. You can use local DBF tables, or connect to SQL Server (or other DB backend), you can call your own UDF functions, and use FoxPro classes to your heart’s content. You write native FoxPro code in a PRG file and you can run and debug in Visual FoxPro interactively against live Web hits. The same way it’s always been with Web Connection.
In fact, Web Connection 5.0 is highly compatible with the previous version (ie. Version 4.x) and 4.x code will run with only a few minor, centralized adjustments. It was very important when the new version released that old applications wouldn’t break with undue changes. There are a few internal changes that require a little tweaking – namely the way error handling works in version 5.0. You can find out the changes that are required for apps from 4.x app here. Several of these changes are not even required, although recommended. According to several of our large customers these changes even on major applications rarely take more than a half an hour to fit onto the application.
The Web Control Framework which is the major new feature in Web Connection 5.x is a set of classes that runs on top of the classic Web Connection engine, using the same mechanisms that have always been used in the product. You have the same Server, Process, Request, Response and Session objects and request routing all still works the way it always has. The Web Control Framework simply is yet another specialized Process class handler like standard method based router, or the Web Service handler and it’s completely optional. If you would like to continue using pure code based Process classes with code in methods that write pure code or use templates and scripts you can certainly continue to do so.
The Web Control Framework itself also is not dependent on .NET in any way. The framework is implemented purely with FoxPro code and basically uses forms based control model. It implements Web forms that contain controls that you can access with FoxPro code to set properties on. The controls can fire events which can be handled with FoxPro code with the framework routing the events appropriatately to your code. It’s all done using FoxPro code. The framework is FoxPro code and you get the code so you can look through it understand it and if you choose extend it.
The misconception about requiring .NET probably comes from the fact that the easiest way to build the visual portion of these new Web Control Framework markup pages is by using Visual Studio or Visual Web Developer (which is free). Web Connection uses these tools as a design surface and integrates with it to bring functionality that simply wasn’t previous possible in Web Connection: A visual designer for page layout. In fact, visual designer support was the #1 feature request I’ve had from customers who’ve used Web Connection. The Web Control Framework basically provides it through integration with Visual Studio. Again, the markup editing in Visual Studio is completely optional – the markup pages are just text and if you rather code them up in the FoxPro editor or Notepad, you can absolutely do that and completely skip Visual Studio – but you will then lose out on the visual aspect of the design experience. We’re already working on support for Visual Studio 2008. It’s not yet working though due to a script mapping bug in VS2008, but it’s functional today and the new designer in VS 2008 really kicks ass and will be even more of an incentive to consider Visual Studio for markup editing.
The integration with Visual Studio works because the Web Control framework is markup compatible with ASP.NET so that the same ASP.NET designer can be used. The framework also provides custom .NET controls for each of the controls it provides as FoxPro controls, so that controls can be visually displayed in the designer and properties be edited with the VS property sheet or Intellisense in the markup. The new controls are not exactly like their ASP.NET counterparts – instead they are more FoxPro centric and use features like control source databinding and FoxPro formatting settings that you are used to in Visual FoxPro that are much easier to use than the equivalent in ASP.NET.
But for you as a developer, there’s no need to delve into .NET – Visual Studio/Visual Web Developer in this scenario are only a designer surface – you can think of it as powerful HTML editor and designer. Web Connection provides an add-in for Visual Studio that lets you immediately preview your pages in the browser and also lets you jump to the FoxPro code for the visual markup directly from Visual Studio with a single click editing your code in the Visual FoxPro IDE or any editor of your choice. And that’s pretty much the extent of the .NET ‘relationship’.
So, if you’re using 4.x do you need 5.x? It’s true that the majority of changes in 5.x relate to the Web Control framework but there have been many, many changes that apply to any Web Connection development. This includes the new wwPageResponse class, which provides a much cleaner Response rendering and access model that lets you add headers at any time with many easier methods to add common headers to requests. There’s automatic support for table based logins, addition of AJAX functionality for both client and server sides, a number of performance and security enhancements to the Web Connection ISAPI DLL including improved logging and more consistent request tracking, automatic cleanup of expired temp files in file mode, Improved Apache support, configuration support for IIS 7 and running under Vista, support for GZip encoding (both in wwHTTP and on the server), a new more performant script parsing engine (for ExpandScript), support for Ghostscript and XFRX PDF output of reports and much, much more. There are also many enhancements to the utility classes and client components. To see all that’s new see the What’s New List.
In short there’s a lot of new stuff even if you don’t care about the new Web Control framework. Many of the improvements are for stability and security and for fixes of issues as they come up. In other words this product is continually updated and improved based on new technologies and environments and yes – your feedback if you provide on the message board.
So where’s the .NET stuff? If you don’t want it you’ll never see it or need it. Web Connection will run fine on a server that has never seen a .NET installation.
So where’s the .NET stuff? If you don’t want it you’ll never see it or need it. Web Connection will run fine on a server that has never seen a .NET installation.
Oh but there is .NET
So what’s the exception I mentioned at the beginning? A while back I built a new Web Connection Managed Module to replace the ISAPI DLL in anticipation for IIS 7 which supports native integration with .NET for low level handlers that essentially provide the same functionality as an ISAPI extension would. This module is completely optional even on IIS 7, but it’s been created for a number of reasons. First it allows for operation under 64 bit Windows without forcing IIS into 32 bit mode which is an important consideration. It also allows using the Visual Studio Web Server or Cassini for development so that you don’t need to use IIS locally. And finally this component provides actually better performance and more flexibility in connector features than the ISAPI extension under IIS 7. The point is the .NET support in IIS 7 and later will make actually for more flexible operation by the Web Connection connector module in the future and protecting the Web Connection investment going forward.
As I’m finishing this up I realized that this sounds kind of like a marketing piece – it wasn’t meant to be really . My main point here is that Web Connection 5.0 has a lot to offer regardless of whether you actually plan on using the Web Control Framework or not.