Avalon Adventures…The Good, the Bad and the Ugly
Avalon Adventures…The Good, the Bad and the Ugly
CAVEAT: before you read this post you need to be aware that the CTP of Avalon is a pre-alpha/pre-beta development tool. Some of the comments in this blog post can be directly attributed to the relative immaturity of the code.
First I am going to start with a confession. Before this process of creating a data enabled Avalon application I was not a real big fan of XAML and Avalon…I was probably a “hater” for lack of a better term.
I’m now more of a fan of this new technology. I am more accepting of what XAML and Avalon provide. I find some of the things in Avalon to be downright cool.
So here are some of my impressions of the current state of Avalon and XAML.
The Good
Data Binding: I think the data binding features of Avalon work pretty well. I like the granular control I have with data binding. You can bind data to pretty much any form, canvas, control and property.
Converters: I was partially successful with converters. I like having the ability to attach code behaviors to properties exposed on controls. I was never able to get the converter working on my list controls. This was more a function of my time than anything. David Jenni helped me figure out what was going on in my code… I just ran out of time to get it done.
XAML: OK, XAML is not so bad… I sort of like the ability to lay out forms using a structured methodology.
The Avalon Team: One item that I found cool was how receptive the Avalon team is to tons of pesky e-mails. As mentioned in earlier blog entries Chris Sells, Anderson, David Jenni, Etc… were very helpful in providing guidance. This is something I find cool about working with folks at MSFT.
The Bad
Documentation: The documentation that ships with the CTP is not as up to date as I would like. There seemed to be a number of deprecated features still in the docs as well as new features that were not very well documented
Sample Code: A lot of the samples provided online did not work with this CTP. Whenever a new CTP is released MSFT should insure that all examples provided on line work with that release. That should be the minimal smoke test for this stuff. From what I recall the Converter section of Chris Sell’s paper has interfaces that were no longer supported.
Few If Any VB Sample Code Online: The world is full of VB.NET programmers too. MSFT needs to make sure samples put online and in MSDN magazine have code written in that “other” language.
Events – There are a number of events that
A) Do not work (list boxes don’t surface double clicks correctly)
B) Have too much granularity – One control I looked at had PenDoubleClick MouseDoubleClick, etc… isn’t a double click a double click ?
C) The Visual Basic Compiler needs to be able to use the Handles command. Currently you are forced to add handlers manually. This is a simple fix and I hope it is in the next iteration.
The Ugly
No Grid (updated 01.19.2005) DataGrid Control – This is a show stopper in a business development environment. In my sample code I had to resort to using a list box to emulate the functionality of a grid for child tables. If Avalon ships without this feature it will not make it in a business environment.
No Development Tools: This is another show stopper. And I’m sure 100% obvious to the team at MSFT. Without a UI designer for creating your XAML forms adoption of Avalon will be slow at best.
Replacing WinForms: The one thing that helps me sleep better is that this technology has may more years to go under development. What I would like to see is XAML become a tool for providing code-gen to create Windows and WebForms. This will help preserve the large investments in Windows and WebForms development while also providing a better migration path. This is what Xamalon is doing now, Microsoft should look at what they are doing and buy them or build their own.