XAML: Rethink How You Code UIs
XAML (and WPF and WF) promise to change how we program. But before you can put it to use, you need a firm understanding of what this technology is and what its strengths are.
by Kathleen Dollard
June 13, 2007
Technology Toolbox: VB .NET, C#
Developers at Microsoft have been busy revolutionizing how we program of late. Nowhere are these changes more evident today than when creating user interfaces (UIs), where, instead of CodeDOM generation of untouchable files, you'll program with the intrinsically declarative model of XAML. No doubt about it: It takes a bit of time to get used to the XAML syntax and other new features. But this powerful core creates a foundation for a wide array of exciting programming possibilities with the potential to upend how we present information in Windows Presentation Foundation (WPF) and manage tasks in Windows Workflow Foundation (WF).
The core features are interesting mostly because of what they empower you to achieve. But you have to step back and understand the sometimes grimy details to use the core pieces to your advantage. XAML is part of a bigger picture that also includes dependency properties, commands, and routed events. This article will help you understand these core features and lay the groundwork for coming articles in WPF and WF.
XAML isn't anything fancy per se; basically, it's the new markup language that describes WPF output and can describe WF workflows. It's a declarative format, which is hard to get excited about because we've been using designers and ignoring the code they generate for years. The hidden partial classes for Windows Forms, Web Forms, and XAML all do the same thing—they describe .NET objects. While XAML may look a lot like HTML they don't do the same things. HTML is interpreted through an engine, rather than by defining runtime objects. Objects defined through XAML are loaded by a XAML reader, such as the ones supporting the WPF and the WF runtimes. XAML is nothing more than object definitions, so it has no flow control or anything that you'd perceive as "code."
Microsoft has implied that XAML makes creating design tools easier, but the current crop of tools using XAML haven't quite lived up to that promise. I am a huge XML fan, so I love that object definitions have moved from obscure and unpredictably formatted .NET code into easily read XML files that emphasize nested containers and properties. I'm looking forward to visual design tools, but not waiting until they get here.
XAML is worth understanding for several of reasons. It creates a language-neutral description of your layout. With a minimum of .NET code in your user interface (most will be in business objects), you can use XAML to minimize investment in today's language technologies. XAML is metadata, so you can also use it to limit your investment in WF and WPF. It will be far easier to write translators from XAML into the next great thing. Another plus: You can create and load XAML at runtime, which makes it easier to create dynamic user interfaces. Finally, XAML enables automatic conversions that simplify code and markup extensions, which in turn simplifies access to shared data and the properties of other controls.
Drill Down on XAML
Like all XML, XAML supports namespaces, and you can map .NET namespaces to XML namespaces, whether framework namespaces or your own. There are two syntaxes for this. You can add attributes to your assembly and write traditional XML namespace declarations, or, more commonly, use the clr-namespace token to specify your .NET namespace, along with a friendly XML prefix such as "local":
Back to top