CSLA and Visual WebGUI

I don't like ASPX. I tried both flavours, with and without AJAX. I hate several things about ASPX

• programming in 4 languages (C#, HTML, Javascript, CSS)
• ViewState

The normal way to write ASP.NET applications is to write stateless pages. You can use a state server but most of time you just use ViewState. Neither one is a good solution. ViewState means your server sends the browser an invisible field with state information. When you post back, the ViewState information travels back to the server. As you might imagine, all this data that is sent back and forth doesn't help your Web application to become faster.

The worst part of ASP.NET is the 4 language issue. I guess I don't need to explain in detail why it doesn't help to simplify the development process or to make it faster for that matter.

Enter Visual WebGUI. No ViewState and only one programming language: C# or VB.NET.

For those unfamiliar with Visual WebGUI, it's a WEB framework that is build around the "empty client" concept. All the developer sees is the full set of Windows Forms controls. You write your code on C# or VB.NET and forget Javascript, CSS and HTML exist. If you have a working Windows Forms application, porting it to WebGUI is really easy. The browser is used just to display the visual side of the controls and to return user input back to the server - the concept of "ViewState" doesn't exist.

• The browser is running a JS kernel that relays low level events to the server: user pressed a key, user clicked at point (X,Y), etc.
• The library handles the low level events like the Windows Forms library does.
• The server is running your application and it doesn't need to reload state everyt time you click somewhere.

This results in applications easier to write:

• one development language only
• you don't loose context between page submissions (you don't have to submit pages)

and applications that run faster

• less data flows server => client => server (namely ViewState)
• application doesn't need to reload context from BD or whatever

Going back to Visual WebGUI sounded like a good idea. From my past experience with CSLA + Windows Forms and CSLA + WebGUI, I knew CSLA needs some UI support classes and UI controls. So I ported them to Visual WebGUI. It was really easy and it didn't came as a surprise, since WebGUI replicates the Windows.Forms namespace.

So I was developing this application. I had the BO and DAL done for CSLA Business Objects library and the UI part was well advanced. The customer wanted a WEB UI but I chose to write two UIs:

• Windows Forms
• WebGUI

The first is used as a test and control project. I put the ideas to screen under Windows Forms. Of course there is some overhead to take this double UI approach. The overhead isn't that big since it's so easy to port Windows Forms to WebGUI.

While it's impossible to find a UI technololy more stable than WinForms, Visual WebGUI has made some very important progress but it's not the most stable technology around. If something doesn't work under WinForms, no bother to try it under WebGUI.

The big advantage on this approach allows me to see in WinForms  what I can expect from WebGUI. If the behaviour doesn't match, I have a WebGUI issue. I could develop directly on WebGUI. If some control didn't behave the way I wanted, it would be difficult to tell whether it was the developer's fault or a WebGUI problem.

So what's the bottom line of this blog entry?

CslaContrib.WebGUI source code was posted on this CSLA.NET thread. In a couple of weeks it will be published on CSLA .NET Contrib Codeplex site too.