Microsoft Live Labs Volta Framework

This is the first post in a series that will discuss some of the new web development frameworks that have come out the past few weeks that revolve around the .NET development platform.

Microsoft Live Labs Volta

Microsoft Live Labs recently released a new web development platform/toolset codenamed Volta (http://labs.live.com/volta/). Built as a toolkit extension package for Visual Studio 2008, Volta removes the developer from dealing with the complexity of rolling out multi-tiered web applications and handling when and where client/server activities take place—that’s all a check box for “on” or “off”.

How does it do it? Well, from what I can tell, with a LOT of JavaScript—almost 45KB of JavaScript between the “compact.js” and “VoltaManagedInteropHelpers.js” files that are attached to every compiled Volta project.

Labs defines the project as:

The Volta technology preview is a developer toolset that enables you to build multi-tier web applications by applying familiar techniques and patterns. First, design and build your application as a .NET client application, then assign the portions of the application to run on the server and the client tiers late in the development process. The compiler creates cross-browser JavaScript for the client tier, web services for the server tier, and communication, serialization, synchronization, security, and other boilerplate code to tie the tiers together.

If you have Visual Studio 2008, you can download the package and give it a try. The most surprising “design requirement”? Volta has built in support for Firefox 2.0 and higher—with debugging tools and all. Impressive and leads more to the fact that not ALL of MSFT is addicted to IE.

I’ll by pass the typical “hello, world” project—you can view that here on the Labs site. The walkthrough details how to create a project, linking to the DOM, etc. What I’m going to create is CIS 100 Project #2–-adding and subtracting two numbers. With this, a bit of discussion regarding the work that goes into this.

NOTE: Before we start, the current CTP (read: alpha) build of Volta seems to have one glitch—there isn’t a way to create NEW pages within Volta Applications. I’m not sure if this is an architectural design decision or simply missing templates. If you try to copy the existing page, it copies, but you can’t rename the embedded resources from “Copy of…”. Annoying.

Elements of a Volta Page

One of the unique aspects, so far, to Volta is the project structure. If you look at your project, you see two files: Program.cs and VoltaPage1.cs. To being, the rest of the logic (specifically design logic) exists as embedded resources to VoltaPage1.

Each page comes three embedded files: favicon.ico, Page.html, and {PageName}.designer.cs.

The favicon.ico is a neat feature that, quite honestly, I usually forget to put in web sites. The “Favorites” icon shows up in, you guessed it, the user’s favorites and in the Title bar when visiting the page.

Page.html is the interface of the page, generated in pure HTML. No .NET controls, nothing fancy—just labels, textareas and buttons. It took me a while to NOT type <asp:…>.

{PageName}.designer.cs is, for lack of a better description, similar to the AssemblyInfo.cs file in other web design projects. It contains the pointers to the html page, icons, and is where you can reference external scripts.

Creating the User Interface / Presentation “Layer”

Now that we’ve discussed the elements of a page, let’s get into writing some exciting HTML. Well, not really, but it’s nice and clean HTML.

Now, we need to “attach” our Volta code to the objects in the DOM. This takes place in the class file for our file. In my case, it’s Calculator.cs. As with a regular WebForms application, the class file inherits from the Page class—except it’s not System.Web… it’s from Microsoft.LiveLabs.Volta.Html.Page.

WARNING: Be careful, classes and objects you MAY be familiar with are reused within Volta—check the full class path when you add in a class, it’s likely you’re attaching to specific Volta objects, not web objects.

Our first task is to create the private variables to hold our DOM objects.

Next, creating the link between our private variables and the DOM objects. This is handled by our InitializeComponent method.

The syntax looks very similar to JavaScript, which really helps out. You’ll also notice that GetById is a generic method, accepting any type of Type you wish to pass to it and keeping everything strongly typed.

Once we’ve specified the private variables, we need a public constructor to build the page and wrap up any events we need, such as clicking on the buttons. You can wrap events two ways: through specifying a new HtmlEventHandler or using a delegate. I’ve demonstrated both here—and both work; it’s a matter of preference.

The GetInputValues method is a quick helper method to refactor out converting the two input boxes from strings to integers.

It’s interesting to note that the generated HTML isn’t identical to what I put in page.html, which means that even the HTML is being interperted by the Volta engine.

Second, the page is slim—even to the point of not having visible JavaScript. At this point, everything is being handled client-side and, I’m assuming, is handled through those two external JS files.

So, how can we change that? We can start by enabling the “Volta tier-splitter” toggle and adding a few attributes to our methods.

Enabling Tiersplitting

Project Properties | Volta | check “Enable Volta tiersplitter”

Next, we can add an attribute to our CalculatorLogic (the Add and Subtract methods) to run those on the server. This can be done two ways. First, right-click on the method and Refactor “Tier-split To Run at Origin”… or just type the attribute.

In my mind, RunAtOrigin is simply another way to say RunAt=”server”.

Run the project again and open the Volta WebServer (swirly pink icon in the system tray). Check “Log Requests” and attempt add up a few numbers. You’ll see now that there is a post back event; however, the HTML code hasn’t changed—Volta is taking care of that.

Now that we’re running on the server, we can add a bit of AJAX into the mix using the Async attribute.

From what I’ve gathered in the documentation and poking around the model, Async methods are called as external methods and require the extern keyword. There isn’t a specified DllImport like you may be used to; I’m assuming the Async takes it’s place—”hey, I’m “outside the client”, so check all the rest of the code for this method.” Hopefully that architecture will be cleared up as further releases come out. For now, it’s just the way it works.

To test this, we’ll add two more buttons: Add Async and Subtract Async. Be sure to add them in all three places—page.html, the private variables, and the init method to link the two together.

The callback parameter replaces the prior assignment used for the non-async method. Using the pattern from the Volta guides, we can use a lambda expression here to specify where the output is going. Also, as you can see, you can use both EventHandlers or inline delegates.

When you run the page, you’ll notice the “delay” (the buttons stay stuck down while it processes) that existed on the regular add and subtract doesn’t exist on the Async buttons.

Conclusion

So far, it’s an interesting technology. Everything I’ve done here could have easily been written in JavaScript—without code behind or anything else—or even ASP.NET WebForms; however, the async stuff is kinda nice and tidy—keeping everything in the CLR.

I look forward to seeing how this project matures and integrates into some of the other new development frameworks, like the .NET MVC patterns. For now, it’s a good start and excellent step in adding functionality we’ve coded around for so long.