Over the last week I've been spending quite a bit of time on non-Microsoft tools building samples for my DevConnections Html Alternatives session. I spend the better part of this week working with Flex and also with Visual WebGui utilizing some existing business objects and Web Services to hook these technologies up.

In case you haven't taken a look at Visual WebGui it's an interesting technology to check out if you need to whip together a utility application or a forms centric Web interface quickly. It's very productive and can literally have you getting usable pages together in a few minutes.

I've checked this tool off an on for about a year or so, and it seems to be improving every time I check back both in stability and visual consistency (which was a problem in the past). What this tool does is provide a Windows Forms based abstraction for Web applications where you can use what looks like the Windows Forms designer to lay out forms and hook up events. VWG maps most of the common WinForms controls and these controls provide a surprising chunk of the full WinForms control gamut.

There are a number of tools out there that aim at this space, but VWG is unique in that it essentially manages server side state of forms - that is it keeps an instance of a form active and has the client code in the browser update the code in this form.  Yup that's not very scalable - and the VWG guys make no secret out of that fact that VWG is not meant for high traffic sites or even for very visual ones. It's a tool aimed squarely at small enterprise and utility apps that are purely forms centric even though there's also support for embedding rich HTML and even XAML content into pages.

However, for many scenarios the scalability it does offer is good enough for internal applications that are used by a handful of people at a time (and I'm sure it'd do pretty well even with a hundred users - some quick load tests seem to bear that out). But the real kicker of this architecture is that the form on the server is essentially stateful so that things like databinding using a BindingSource control actually work the way you'd expect on the Web. You can set a form property and hit another button and that form property - set on the server - remains valid between callbacks. For example, you can load a business entity object as a form property, bind to it to display data and that object stays loaded between callbacks. You can then simply unbind the data and read it back or even have the binding source stuff the data back intot he database automatically. It's an interesting concept that feels very strange in a Web application but it's also extremely liberating in some ways as it makes for very rapid development compared to the typical Web page and the state recovery you go through normally.

One problem: LINQ to SQL's DataContext

Incidentally I've been using my TimeTrakker LINQ to SQL business objects for the business and data access in all of my samples and it's been working well for standard ASP.NET based pages, clients that use service based access to the data (Flex and Silverlight) and also with Visual WebGui now.

However, I found that I could not get DataBinding with LINQ to SQL to work correctly when trying to save data. I can get data to bind in just fine, but when trying to save the data back to the database by calling SubmitChanges I end up with errors immediately to the effect that basically all fields are null.

After a bit of spelunking around it seems that even through the business object and the related entities on the form stay alive and have the correct state associated with them, the LINQ to SQL DataContext somehow disconnects as part of the Visual WebGui state management - or more likely - the invariable thread switches that might be occuring as part of the callbacks. Looking at threads I noticed that calls didn't always land on the same thread and that likely accounts for the issues the DataContext is having keeping its data straight.

Solution: Ditch the WinForm style databinding and manually bind, using new instances of the business object for each operation. So when binding back a the original object is loaded and the values from form input are bound to the existing values (or in the case of a new entity to the new values). This is the same thing that would be done with remote Web Service calls, except in this case the business object can be instantiated and accessed directly. This does wor fine and apparently is a requirement in this scenario.

Yet another gotcha to watch out for with LINQ to SQL - persistance and/or thread switches can cause havoc with the L2S DataContext.

Different and Intriguing

Visual WebGui is intriguing. It's ridiculous how productive you can be with a tool like this compared to building an ASPX page. But somehow it feels like cheating <bg>...

This tool is clearly not for every Web scenario - it's squarely aimed at forms centric scenarios and more specificallly at WinForms developers. But given of how many times I've heard the question of "How can I build a WinForms like application for the Web?"  or "How can I migrate a WinForms app to the Web quickly?" that's not as far fetched as it might sound in the first place.

And even if you are a hardcore Web developer and you need to whip up something in a hurry this is an option.This tool can address a number of down and dirty Web app scenarios very effectively and more importantly more rapidly than any other Web tool based on the .NET stack that I can think of. Even if the author seems a bit arrogant towards ASP.NET as an inefficient  technology - ha. Check your ego at the door please <g>...