Last year I spent a ton of time working with "Avalon", now known as Windows Presentation Foundation (WPF). I wrote about this on my blog under the title Avalon Adventures. With a lot of time, sweat and help from folks at Microsoft I managed to build a rudimentary data entry application. The focus of my research was to see if Avalon was capable of building applications for line of business. I came to the conclusion that Avalon still needed a lot of work. I wrote up my conclusions under a blog entry called "Avalon Adventures: The good, bad and ugly".

http://blogs.officezealot.com/rod/archive/2005/01/18/3885.aspx

This winter/spring I did a number of presentations in Canada to demonstrate how to use WPF for creating line of business applications. The experience this time went much smoother for a number of reasons which I will illustrate below. I also had some similar experience in the bad and ugly departments as well.

The Good

More Controls Now

Over the last year a number of new controls were added to WPF. Menus, progress bars, tree views, rich text editing. This is definitely a positive direction. Overall the mix of controls is getting richer with each version. It will take a long time before the collection of controls is on par with what we have in Windows forms but the story is definitely getting better..

XAML Markup

XAML as a UI Markup Language is really cool. The more and more I work with XAML I find its mechanisms for specifying UI very nice. It is very easy to follow how a form is intended to be laid out.  Windows Forms should have done this from day one. XAML has some flaws in that it has the potential to become mind numbingly complex and I am not 100% how this stuff will be "debuggable"

Styles Rock

In this last round of my experimentation I fell in love with the concept of applying <Style> tags. The cool thing is that <Style> tags allow you to specify the look and feel for all components in your application. You can specify the color, font, font attributes, etc at the highest level of the application. The most interesting aspect of this is that these specifications occur at the Type level. Meaning you can specify that all objects that inherits from the Control class have specific attributes.

WPF Books Now On Sale

Publishers have released some good books on WPF. One of the better ones I have used is Programming Windows Presentation Foundation by Chris Sells and Ian Griffiths.

http://www.amazon.com/gp/product/0596101139/sr=8-2/qid=1147036056/ref=pd_bbs_2/103-5182252-4199047?%5Fencoding=UTF8

There is also a new book in the works from Charles Petzold. You can follow his progress in creating his book at

http://www.charlespetzold.com/blog/blog.xml

There is one caveat about the currently shipping set of books. The ones I have read are out of date in a number of areas. The XAML specification is rather fluid and a number of sections of these books are simply incorrect.   I know like Chris Sells provide errata on his blog (www.sellsbrothers.com).

Data Binding Still Rocks

I still love the very granular control of Data Binding in WPF. Pretty much every control in WPF has a property called DataContext. You use this project to attach data to your individual controls. This data can be XML, ADO.NET DataSets or custom objects. You are also not limited to one type of data for your form. One control can be bound to an ADO.Net dataset while another can be bound to an object.

3^rd Party Market

There is a small 3^rd party market now. At the last PDC we saw controls from Infragistics that solve the problem of a missing grid control (more on that later). I expect that Infragistics, Component One, Developers Express and other vendors are hard at work on there WPF control sets. There is also a product called Aurora from www.mobiform. Aurora is a very nice XAML design tool.

VB.NET Citizenship

Being a VB.NET MVP one complaint I had was the lack of constructs familiar to VB.NET developers. One item that I really like about VB.NET is the Handles statement. This statement allows you to attach an event to a subroutine. This feature has been implemented. Thanks WPF team for that.

The Bad

Manual XAML Coding Required

Out of the box you are still required to hand code your XAML. Cider (discussed below) is a weak tool for doing layout and provides very limited control of your XAML form development. Aurora (mentioned above and below) is a better tool than MSFT's offering.

Weak Background Compilation of XAML

When you manually code your XAML your controls don’t consistently show up in the code behind. In other words if you add the following control <TextBox ID="txtLastNane"> you won't see this object in code behind files Intellisense until you manually compile your code.

XAML Specification Fluidity

The specification and underlying technologies for WPF and XAML seem to be very fluid in nature. Every version contains breaking changes. This is to be expected in a brand new technology like WPF. But at some time this needs to slow down.  Still I feel the spec needs more revision at this point. XAML is inconsistent in a number of areas and needs more work to improve consistency.   

XAML Inconsistencies

One of the goals of .NET was to add some level of consistency. All classes inherit from objects, have a ToString method, have a GetType method, etc. UI elements in WinForms have a Text element rather than one having a Text element and another having a Caption element (as we faced in VB6). This same careful attention to detail missed the XAML team. For instance:

<Button>Hello World</Button>

<Menu>

<MenuItem Header='Rodman'/>

</Menu>

Why do these two elements have greatly different markup for a common task. Either the <Button> element needs to have a Text attribute or the <MenuItem> element needs to support markup similar to the <Button> element. I think MSFT needs to look at this before they ship.

Stale Blog Code

There has been a lot of work on WPF by numerous bloggers. When you Google stuff on WPF you often come across Blog entries written for old versions of WPF.  Because of the fluidity of the XAML spec these are often grossly out of date. I am guilty of this as well. I know for a fact none of my old blog entries will work with current versions of WPF. This is not the fault of the teams at MSFT just a statement of warning about old examples. Maybe we as bloggers should tag our articles on what version of WPF (or other technology) they will still work with.

The Ugly

Weak Flavored Cider

Cider at this point (based on the Feb 2006 CTP) is just plain weak. Cider is the code name for the WPF tools that integrate with Visual Studio 2005. Basically all Cider provides at this point is a mechanism for dragging and dropping controls onto a WPF form. It has some rudimentary control over properties but thats about it. This tool needs lots of work. I wouldn’t even go as far as calling this tool Alpha. Microsoft needs to reconsider putting tools out that are in this early stage of development.

FWIW there is a pretty cool UI designer tool called Aurora. Aurora is from a company called Mobiform and can be found at www.mobiform.com.  From what I can tell Aurora is written in WPF. It is hands above better than Cider.

CAVEAT: I have not played with Sparkle which is a standalone XAML/WPF editor. I am looking at this from the developers standpoint and the tools that work in VS.NET. From what I have read/seen about Sparkle this technology looks pretty cool. But it is geared much more for designers and not developers.

Documentation is Still Lacking

It is really frustrating to work with a new technology that is so poorly documented. This has been the case in the software industry for decades and I am not sure if it will ever change. In my opinion every class and its properties, events and methods should be documented with an example. I can't understand how a company that has a specification process as good as Microsoft can keep churning out documentation that is so poor. MSFT is in the business of building tools for developers they should explain how to use them. Every specification should include an example of a properties use. These examples should change as the specification changes. Automated tools could then extract these examples from the specifications. This is much like XML comments in classes in .NET.

XAML is Difficult/Impossible to Debug

The compiler for XAML needs to come up with useful errors telling developers what is clearly wrong with there markup. XML namespace mismatch errors are insufficient. The XAML team needs to take a look at the VB helper technology that looks at an error and does its best to suggest a proper fix to a problem.

Missing Grid Component

Sill ugly and MIA from all releases so far. This is still the most obviously missing component. The reaction from developers is always the same when I point out this short coming…. WHAT!?!?!?!?!?! How could they have missed that one?

Is WPF Ready for Prime Time?

In this authors opinion no. WPF as a technology has a number of really cool features. The Good section of this post is sure getting "Gooder" (Thanks Mr Bush J). But this technology still has a ways to go. I think some of the shortcomings will limit its adoption by mainstream developers for some time. The developer tools story needs to improve greatly.  Debugging needs more work. WPF is definitely a 1.0 version and I feel its adoption will happen when its 2.0 version releases.