I’ve been heads down buried in FoxPro code for the last week and a half or so working on Web Connection 5.0. The core new feature is a new page framework for Web application that allows the ability to write object based code for managing Web pages.

 

At the core of this new model is an object framework that is based loosely on ASP.NET controls and structure providing the same sort of functionality in terms of auto-postback, page state management, event handling and much, much more. As previously mentioned I posted some early samples of what this stuff looks like here:

 

http://www.west-wind.com/wconnect/webcontrols/

 

No, not very flashy demos but if you play around with them and look at the code behind them you’ll see that this looks very different than stock Web Connection applications. One key feature is the ability to use a visual editor – specifically a .NET capable editor – to create your pages. Web Connection 5.0 highjacks any editor that is aware of .NET controls and allows using a number of the stock ASP.NET controls. There will also be an assembly of controls shipped that matches the controls the framework provides. And yes you don’t need VS.NET (or WebMatrix, Visual Web Developer) although those will likely give the best design experience. You can use any text editor of course to edit the markup pages (you can look at the view WCSX page links to see what the markup looks like).

 

As I slowly leaked some information a few people asked the obvious question: Why bother? <g>

 

Obviously this framework will not provide the full breadth of what ASP.NET provides, although I think it’s already providing a highly functional base set that I at least typically use in ASP.NET applications. But still why bother right? After all if you want to paradigm just use ASP.NET.

 

There are still lots of Fox developers out there who do not want to migrate to .NET. The Web Connection customer base is still very strong with a constant flow of upgrades and new purchases to this date, which indicates that there is definitely still life left in the FoxPro market. For many folks FoxPro is their tool of choice and this tool is aimed at them.

 

It’s an interesting focus actually as this framework provides a ton of power and makes things easier in many ways, but at the same time it raises the bar of complexity a bit. Standard Web Connection code can be anything – and often is very procedural. Coding with this interface is a lot more like Window application development where implementing methods and handling events is the call of the data (pun intended <g>). There’s more happening here – you need to manage a script page and a code behind PRG file, but I think the payoff is tremendous.

 

For existing Web Connection users it brings an easier multi-developer scenario (each page is a separate file and PRG), it provides a much easier way of dealing with complex pages where code is logically grouped into separate methods of a class, and the entire page pipeline provides more flexibility for manipulating content simply by referencing controls that render when the page is drawn.

 

In addition, Web Connection didn’t provide a good extensibility model previously. It’s easy to extend at the application level, but unless you wanted to re-write process class level code you were pretty much stuck with the base behavior. Extensible yes, but not much. With the new page framework anybody can build new controls and plug them in. Re-usability is a big thing in this scenario. Extensibility as well. Don’t like something about the controls: Subclass them and extend. There are many built in hooks that make this very easy without completely throwing out the code. In addition, the new controls – at least the stock ones – can work standalone so while the work best in the page framework they can run standalone without any problems. For example, the new DataGrid can be plugged into straight Process Class code just by setting a few properties.

 

 

However many of the more advanced users have over time either built their own control frameworks or used Markus’ Voodoo Web Controls, which did a lot of what this framework does several years back (which of course both are basically plagiarizing ASP.NET <g>) . The one thing that was missing for Voodoo was some sort of visual editing support…

 

This framework will address the visual portion through template pages that look very much like ASP.NET pages and take those pages and parse them into compiled PRG files (much like the way ASP.NET compiles its pages into assemblies). You can use VS.NET and many of the stock Web Controls and they will work as is. But it’s important to understand that it isn’t Web Connection’s goal to work with all the .NET controls. We’ll implement the core controls and a few useful custom controls, but by no means do we have the resources to match all ASP.NET Controls. Nor do I think is it necessary. For 90% of development use a core set of controls, which is what we’re focusing on in this first release. In addition there will be a number of custom controls (you can see some of these in the ErrorDisplay control and the Show Code control in the demos) that provide non-standard functionality that is quite useful and common.

 

As to working with ASP.NET style templates, during development the process is dynamic – you make a change to the page and you can simply re-run the page without stopping the server or recompiling. The framework manages parsing and compilation of the code. For deployment and flipping a switch dynamic compilation (which is relatively slow) can be turned off and pages run in full compiled mode as FoxPro PRG code.

 

Comparing to ASP.NET there are a number of things that FoxPro does very well – specifically data binding and display. List based binding is as simple as running a query and pointing a list based control like the grid or list at the cursor with the DataSource property. Easy. But even better because VFP is a bit more dynamic and doesn’t rely on strong typing you can very easily bind to complex expression and apply format expressions that can be anything from fox format strings to UDFs and method code that excecutes. Binding data back as well is a matter of a couple of lines of code – BindData to bind to business objects, or database fields, and UnbindData to simply bind the data back.

 

The samples look very simple and they are in what they actually accomplish but there are a lot of little things demonstrated in there that would take reams of stock Web Connection code to write. So if you’re interested play around with the stuff and look at the code and script.

 

 

Working on this stuff is a blast

It’s been a while since I’ve had some challenging work to do and this project is turning out to be a lot of fun, although there is also a share of frustration. The FoxPro garbage collector is killing me and trying to make 100% sure there aren’t any circular references in this type of application framework is very difficult to accomplish in VFP. I just got done tracking down one of those references where I forgot a simple call to the Dispose method of a control – it took nearly 3 hours to track that one down. No fun at all, that…

 

It’s interesting though how quickly all of this has come together in such relatively short amount of time. I’ve been wanting to this for well over 2 years now and I finally got motivated to hunker down and do it. The core work is pretty much done but there will still need to be a lot of work to be done creating more controls and dealing with open issues in the parser. I spent the day today rewriting the parser from the ground up using pure Fox code instead of the nasty RegEx expressions I was trying to make work for most of the parsing. Not only is the hand parsed code an order of magnitude faster, but it’s also a lot more flexible (although pretty messy).

 

A lot of people have expressed interest and I’m hoping to be able to get something into the hands of those who want to play by next week. It’s still early so it will definitely be an early beta affair, but I am very interested in feedback and providing functionality that people are interested in.