Yesterday I watched the PDC video about XAML called Microsoft .NET Framework: Declarative Programming Using XAML. It was pretty interesting and it had a list of some of the new features we can expect to see for XAML in the next version of the .NET framework. Here is a brief laundry list along with my (interpreted) explanation.
Better Name References
It used to be you had to create references to other elements using the ElementName property of Binding extensions. Well it seems now that they have created a simpler x:Reference markup extension which will be the default for properties such as the Target property of a Label. Meaning you only have to write the name of the element to get a binding to another control in some places.
XAML 2006
|
<Label Target=”{Binding ElementName=firstName}“>First Name</Label>
<TextBox Name=“firstName” />
|
XAML 2009
|
<Label Target=“firstName”>First Name</Label>
<TextBox Name=“firstName” />
|
Expressions:
Interestingly enough they also touched on a new feature called expressions. The full power and syntax of expressions wasn’t fully explained but at first look they could be extremely useful. Below is an example of an expression that is the string literal “Hello” plus the value of the default property of the firstName element (being that it is a textbox I’m assuming the default property is the Text property).
|
<TextBox Text=‘[“Hello ” + firstName]’ />
|
Built-in Types
Currently you have to hook up some gnarly xmlns reference to get access to basic types. They are including access to the most common basic types by default into the ‘x’ namespace for us.
XAML 2006
|
<s:String xmlns:s=“clr-namespace:System;assembly=mscorlib”>Foo</s:String>
|
XAML 2009
|
<x:String>Foo</x:String>
|
Generics support everywhere
This is very intriguing, clearly this should be useful. I was fully expecting them to come up with something very clever and much more terse then what I see here (new syntax) but what they came up with was actually probably very easy to implement. They simply created a new attached property that stores the type arguments. I’m assuming if you have multiple type arguments you would separate them with a comma.
XAML 2006
|
classPersonCollection : ObservableCollection<Person>
{ }
<c:PersonCollection>
<c:Person Name=“Dan” />
<c:PersonCollection>
|
XAML 2009
|
<ObservableCollection x:TypeArguments=“c:Person”>
<c:Person Name=“Dan” />
</ObservableCollection>
|
My proposed generics syntax
If I was going to implement a generics syntax I probably would have favored something more like this
|
<ObservableCollection[c:Person]>
<c:Person Name=“Dan” />
</ObservableCollection>
|
Support arbitrary dictionary key types
I haven’t experienced this as a pain point in doing WPF XAML but it seems that this feature is targeting WF more than anything. Note the example also combines examples of expressions, generics and simple type references. I bet the WF people will be happy about this one.
XAML 2006
|
<x:Key>…</x:Key>
|
XAML 2009
|
<Switch x:TypeArguments=“x:Int64” Expression=“[rating]”>
<Sequence x:Key=“10”>…</Sequence>
<Sequence>
<x:Key>9</x:Key>
</Sequence>
</Switch>
|
Beyond Method Names
Honestly I couldn’t quite fathom what he was talking about here. This must also be more targeted for WF people because I can’t really see how this would impact WPF at all.
XAML 2006
|
<Button Click=“button_Click” />
|
+ markup compilation
|
XAML 2009
|
<Button Click=“button_Click” />
|
|
Also:
|
<Button Click=”{Delegate Foo}“ />
|
|
Better declarative Type Authoring
Once again, this appears to be an improvement mostly for the WF crowd. After talking to Rocky Lhotka briefly he explained that it would be extremely useful to be able to declare your properties as In or Out arguments so that consumers your activities would know what to expect.
XAML 2006
|
<Window x:Class=“WpfApplication1.Window1” … />
|
XAML 2009
|
<Activity x:Class=“ActivityLibrary1.Prompt”>
<x:SchemaType.Members>
<x:SchemaProperty Name=“Text” Type=“InArgument(x:String)” />
<x:SchemaProperty Name=“Result” Type=“OutArgument(x:String)” />
</x:SchemaType.Members>
</Activity>
|
Non-default constructors
This sounds useful in general, coupled with simple type references it seems pretty easy to get any type of object you want.
XAML 2006
|
<x:DateTime>00:00:00.0000100</x:DateTime>
|
XAML 2009
|
<DateTime>
<x:Arguments>
<x:Int64>100</x:Int64>
</x:Arguments>
</DateTime>
|
Use static factory methods
I’m really happy to see this one, the lack of support for factory methods was pretty disappointing to me in the past. The workaround was to use an ObjectDataProvider and specify the MethodName property, which would, unfortunately, force you to have a public default constructor for your object before it could get to your factory. This really messes with your object model, now we should be able to go directly to a factory method. There are still benefits to using the ObjectDataProvider though, I hope there is a way to get the ODP to access the factory methods without requiring a default constructor too.
XAML 2006
|
Guid guid = Guid.NewGuid();
|
XAML 2009
|
<x:Guid x:FactoryMethod=“Guid.NewGuid” />
|
Composes with x:Arguments
