Surprise, surprise. If you know anything at all about WPF, you’ll have heard of XAML (eXtensible Application Markup Language). At it’s simplest level, it’s the replacement for the designer.cs that you get when you create forms in Windows Forms.
Whereas WF uses programmatic statements one after the other to create content, XAML is an XML-based hierarchical, declarative markup language much like HTML designed to store your form content. So, you might have content looking something like this:
<Window> <Panel> <TextBox>Hello World!</TextBox> </Panel> </Window>
This is a crude example that wouldn’t even compile but you get the idea. It would probably map in C# to creating a Panel and then doing a Panel.Controls.Add (new TextBox()); or whatever.
XAML is very powerful. They’ve taken some of the good ideas out of web design and brought them into the .NET world, such as styles (similar to css), as well as the ability to declaratively linked presentation to events e.g. you may have a style for a button to use when the mouse is over it and another for when it has focus – you can do this all inside your XAML without having to write any C#.
In terms of performance, it’s not interpreted or anything like that – at compile time it gets turned into a binary form within your assembly so it can be read very quickly. Although you probably don’t need to know this, WPF also uses DirectX extensively (even for non-3D graphics) and almost 100% does away with the reliance on GDI and user32.dll etc. that Win32 and Windows Forms uses. If you have a decent graphics card, this means that it uses that for rendering and calculations and takes advantage of all your cards features.
There are a few ways of writing your XAML within the context of an IDE – the most obvious choice is Visual Studio. VS2008 and 2008 Express Edition both have integrated XAML designers with a neat split view so that you can see your UI and your markup at the same time:
This view can be resized and changed to a vertical split, or you can opt to just work in XAML or Visual Designer mode.
The Visual Designer is mostly the same although some things have been streamlined and enhanced depending on the control that you’re working with. Firstly there’s a handy document outline which, as with “regular” XML documents, lets you walk the tree of elements in your markup and see the hierarchy.You also get a handy little breadcrumb on the bottom which shows you the branch that you’re currently on; leaving the mouse over an crumb will give you a visual tool-tip of that item downwards – neat.
There’s also a rich collection of ready-made controls, most of which are pretty similar to their original WF counterparts although most are different enough so that you can’t just jump straight in and carry on as normal. You can either drag-and-drop controls onto the page, or simply enter the markup for them directly into your XAML and the controls appear in the Designer pane. This is my preferred way of doing things currently, because when you drag controls on, VS tends to set extra properties and attributes that you may not want on. Plus, I want to learn what all the attributes do, and just using the designer isn’t the best way of doing that in my opinion.
Another option – and probably the “ideal” scenario in professional development environments – is to have a specialised XAML graphic designer who works on the UI of an application whilst the application developer handles the programmatic side of the app. However, this does not mean that the designer would need to learn how to use Visual Studio. There’s another application, Expression Blend (is it still called that? It’s gone through several name changes since it was in beta) – a Microsoft application that is geared towards creating XAML UIs. This comes with a lot more tools for generating XAML, styles and so on – but it also understands VS project file formats and even C# (although the C# editor is, as expected, crude). So one person could be designing the XAML in Expression Blend whilst the coder is working on the code behind – when the design makes changes to the XAML, the developer gets the latest look-and-feel.
I suppose that this is the logical progression for where MS is going with UIs – in .NET 2 they introduced partial classes as a means to separate the designer.cs from your main code-behind; now they’ve pulled it out even further. There are several benefits to XAML:
– Provides a mechanism to completely separates the UI from the code – although you can still add controls programmatically if you really want to. But having used XAML now, that method just seems ugly and slow to write. I would never write a Form in WF manually, but in WPF it seems quite doable for relatively simple ones.
– You can spit XAML out to be rendered in a browser as well. Obviously if you want the code behind to work as well (like Java Applets) then you’re looking at extra deployment requirements and security (look at XBAPs) but it’s definitely possible.
Of course, there are lots of things that you can do in XAML that would have required lots of coding in the WF world – I’ll talk about them in future posts.