Those of you, who have already developed with WPF “and” Silverlight might know, that Silverlight contains a different XAML-Parser than WPF does.

Some days ago I read on the blog of Rob Relyea a great post about the XAML-Compilers, which create the g.cs- and (only for WPF) the .baml-Files. Rob is talking about improvements for future versions of the XAML-Compilers. Find the post here:

http://blogs.windowsclient.net/rob_relyea/archive/2009/08/25/msbuild-pipeline-for-wpf-amp-silverlight.aspx

I asked in a comment, what about the XAML-Parsers, and Rob has started a new discussion about that topic (Thanks a lot for that) and quoted my comment. So read on here and then go over to Rob’s post and write your thoughts about improvements of the Silverlight XAML-Parser to the Comments-section of his post:

http://blogs.windowsclient.net/rob_relyea/archive/2009/09/08/silverlight-xaml-developer-experience-issues.aspx

Below I’ll summarize my top 3 features I miss most in Silverlights XAML-Parser. All of them exist in the WPF-XAML-Parser:

1. Direct Content with ContentPropertyAttribute

Support direct Content for all Elements that have a ContentPropertyAttribute set on it’s class-definition. E.g. the following doesn’t work in Silverlight yet.

<Button>OK</Button>

In Silverlight you have to do it this way:

<Button Content="OK"/>

This also means you can’t make use of the ContentPropertyAttribute, if your Content isn’t placed in its own element. Take a look at the Friend-class below.

[ContentProperty("FirstName")]
public class Friend
{
  public string FirstName { get; set; }
  public string LastName { get; set; }
}

In WPF you could write the following which not works in Silverlight:

<local:Friend>
  Mary
</local:Friend>

In Silverlight you have to write it the following way using the Attribut-Syntax, which also works without using the ContentPropertyAttribute:

<local:Friend FirstName="Mary"/>

In Silverlight you could also write it this way, by placing the content in its own element.

<local:Friend/>
  <sys:String>Mary</sys:String>
</local:Friend>

Especially if you create custom classes you want to use in XAML, the ContentPropertyAttribute could be very useful.

2. Support for the XmlnsDefinitionAttribute

Also the XmlnsDefinitionAttribute-class exists in Silverlight, you cannot map your own CLR-namespaces with it. You get an “Unknown Namespace”-Message, if you try to use it. In WPF the Attribute is used on assembly-level like below:

[assembly: XmlnsDefinition(
  "http://www.thomasclaudiushuber.com/xaml/thoughts/2009",
  "Thomas.Xaml.Thoughts")]
[assembly: XmlnsDefinition(
  "http://www.thomasclaudiushuber.com/xaml/thoughts/2009",
  "Thomas.Xaml.Thoughts.Controls")]
[assembly: XmlnsDefinition(
  "http://www.thomasclaudiushuber.com/xaml/thoughts/2009",
  "Thomas.Xaml.Thoughts.Data")]

In XAML all the three CLR-Namespaces above could be mapped to one XML-Namespace by using the specified string:

xmlns:thomas=
"http://www.thomasclaudiushuber.com/xaml/thoughts/2009"

Especially for building librariers consisting of more than one CLR-Namespace, it would be great to support the XmlnsDefinitionAttribute, so that a library developer can map all his CLR-Namespace to one XML-Namespace that is used in XAML. That makes the usage of the libary in XAML very compact.

3. Support some missing Markup Extensions

There are also some missing Markup-Extensions in Silverlight. The following would be very great:

• x:Static – allows you to reference Static Members from XAML.
• DynamicResource – references a resource and get’s the changes to the resource. Even if a resource with the same key is defined dynamically on a lower level of the Element Tree, this MarkupExtensions grabs the new one
• x:Type – create a Type-Object of a specific class in XAML

Other thoughts…

… about Markup Extensions

1. Custom Markup-Extensions

If you dig deeper into Silverlight, you’ll notice that there is no support for Custom Markup Extensions. Some Extensions are integrated into the XAML-Parser, and some implement the IMarkupExtension interface as Reflector shows.

In WPF every Markup Extension inherits from MarkupExtension. So you can create your own one by inheriting also from this class and overwrite its ProvideValue-Method. This would be a great feature for Silverlight 4, but as the base-class isn’t in Silverlight yet, there would be “some” things to change.

2. Visual Studio 2010 Beta 1 Intellisense for Markup Extensions

Visual Studio 2010 Intellisense supports Markup Extensions. But it creates e.g. a StaticResource the following way:

<TextBox Background="{StaticResource ResourceKey=myBrush}" />

In Silverlight specifying the ResourceKey-Property explicit isn’t supported. The upper syntax one matches WPF. In Silverlight you’ve to use the markup Extension this way (which also works in WPF):

<TextBox Background="{StaticResource myBrush}" />

Personally I prefer the last way without specifying the ResourceKey-Property explicitly. Maybe this could be done by the Visual Studio team instead of extend the XAML-Parser of Silverlight.

… about x:Name-Attribut

The x:Name-Attributes allows you to give Elements in XAML a name, and access them via Codebehind-File. While WPF supports all elements to have an x:Name-Attribut, Silverlight only supports those deriving from DependencObject.

Even if most classes derive from DependencObject, naming other classes in XAML would by great.

… about IDictionary

Seems that the Silverlight-XAML-Parser is hard-coded to the ResourceDictionary. In WPF you can initialize every collection that implements IList or IDictionary. In Silverlight you can initialize every collection that implements IList or is a ResourceDictionary. It’s not a big issue, cause most times a dictionary is created in code.

So these are my thoughts and wishes for a new release of a Silverlight XAML-Parser. Thanks for reading and now place your own suggestions into the comments section on robs blog here