A One-stop Shopping XAML Namespace for Silverlight Client SDK Controls
A feature that was added to Silverlight 4 that hasn't garnered much attention so far is the sdk: XAML namespace prefix. This prefix provides a common URI-based XAML namespace that ALL of the most commonly used client SDK controls can share.
Let's have a look at how this worked before, in Silverlight 3 (and in the Silverlight 4 beta, for that matter).
In Silverlight 3:
To use a control that comes from one of the SDK client libraries in XAML, you had to specifically define a XAML namespace. The XAML namespace was defined based on an assembly name (the SDK client library assembly) and exactly one of the CLR namespaces within it. Then, that XAML namespace is assigned to a prefix. (Or if you think of it in a left-to-right way in actual XAML, the prefix gets defined to an xmlns first, and THEN you declare the CLR-namespace and assembly.)
For example, to use DataGrid, you needed this definition in the root of your XAML:
xmlns
:data="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data"
Then, in the XAML, you always needed to prefix DataGrid with that prefix:
<data:DataGrid ></data:DataGrid>
This doesn't get too ungainly, until you start integrating multiple SDK controls into the same UI page. Say, a DataGrid and a Calendar. Or DataGrid along with inline styles that access the component parts in the .Primitives namespace (requiring a separate mapping). Before you know it, you have four or more mapped namespaces even though you might only be referring to one or two assemblies. And now you need to remember which prefix means which, and type that prefix, before VS Intellisense even lets you see the types that are accessible.
In Silverlight 4:
You still need a prefix. Don't get too excited :-)
But, each of the client library controls, namespaces and assemblies now support a XAML namespace that is identified by URI: https://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk
Don't want to remember the URI? You don't have to. You only need to map the URI to a prefix (like sdk:, or whatever you want), and you do so just once in the root of your XAML.
Don't even want to do that? OK. Just use VS, and it will do the job for you.
Start from a totally brand new Silverlight Application project. Pull up the Toolbox. Drag and drop one of the client SDK controls (like DataGrid) out of the Toolbox and into your Visual Designer.
Magic! If you now look in the XAML text editor, this action of dragging something from an SDK assembly into your UI adds the root mapping to sdk: for you. And the magic continues. Because if you now drag in Calendar (which previously would have required a different XAML namespace mapping) it can use sdk: prefix too!
Here is a table of all the CLR-namespace and assembly combos that are now all subsumed by https://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk AKA the sdk: prefix:
Assembly |
CLR Namespace |
|---|---|
System.Windows.Controls |
System.Windows System.Windows.Controls |
System.Windows.Controls.Data |
System.Windows.Controls System.Windows.Controls.Primitives |
System.Windows.Controls.Data.Input |
System.Windows.Controls |
System.Windows.Controls.Input |
System.Windows.Controls |
System.Windows.Controls.Navigation |
System.Windows.Controls System.Windows.Navigation |
System.Windows.Data |
System.Windows.Data |
There is one little wrinkle to this story: control templates. The default control templates are physically a part of the assembly, either the core assembly or the library assembly. These templates need to work for either a Silverlight 3 or Silverlight 4 target. Thus for compat reasons the control templates continue to use the specific CLRNS+assembly mappings, not sdk:. That is an implementation detail at some level, but it will impact you too, if you use these control templates (either as provided in documentation, or as extracted out of library resource) as the basis for a custom control template that overwrites one of the client control's defaults.
But not a big deal. VS has an elegant behavior for this case too. So long as mappings already exist in the root XAML, even if they are the v3 style mappings, VS will continue to use them both for Toolbox drag-drop and Intellisense purposes. And thus when you start from the templates that already have those mappings, you can just keep using them. In fact, if you really want to confuse yourself, you can have both styles of mappings and thus have two prefixed ways to access the same type, using either or both of them in the same XAML file.
One last wrinkle, but this one is WAY minor. System.Windows.Controls.Primitives namespace from System.Windows.Controls assembly somehow didn't rate being included in the sdk: namespace. Sad for it. But probably you don't care ... the classes in there are not often used, except for Calendar recompositing.
Here is another recent blog post that also discusses the sdk: prefix, as well as a number of other callouts to XAML behaviors that are new and improved in Silverlight 4:
https://www.davidpoll.com/2010/03/15/new-in-the-silverlight-4-rc-xaml-features/
(Post edited to now refer to Silverlight 4, since we are now RTM. Yay!)