I recently had a question about the differences in StartObject and GetObject in XAML so I wanted to go over it here.
In a nutshell, StartObject means create the object and GetObject means we should call the parent property’s getter to retrieve the value and use that as the instance instead.
StartObject
This is used when we want to create the instance of the XamlType specified. Normally, this means we just call the default constructor. In XAML 2006, we could also call TypeConverters with the text specified in the content and also call non-default constructors in MarkupExtensions.
<Button/> – Default constructor
<Brush>Red</Brush> – Calling the TypeConverter
In Xaml2009, we also added support for factory methods and non-default constructors (using x:FactoryMethod and x:Arguments). (You can also pass arguments into FactoryMethods)
<sys:Guid x:FactoryMethod=”NewGuid”/>
<sys:DateTime>
<x:Arguments>
<x:Int32>2010</x:Int32>
<x:Int32>3</x:Int32>
<x:Int32>18</x:Int32>
</x:Arguments>
</sys:DateTime>
Node order dependencies
One of the important things to note though is that because these “construction” directives (Arguments, FactoryMethod, Initialization, PositionalParameters and TypeArguments) come after the StartObject in the node stream, we can’t actually create an object the moment we see the StartObject node. We have to wait until we see all the construction directives first. So, the XamlObjectWriter will wait until either 1) we see a start member that’s not a construction directive. 2) see a EndObject (because there are no properties being set. 3) We process a construction directive that results in creating the object. Initialization & PositionalParameters would trigger construction.
This all means that the XamlObjectWriter has an order dependency on how nodes are passed into it. While we considered having the XamlObjectWriter buffer and sort things out, we decided against doing that because of performance. While some XamlReaders like XamlXmlReader could have benefitted from having the ObjectWriter sort, there are other readers like the Baml2006Reader that wouldn’t benefit from this (since the XAML Compiler reorders and optimizes the nodes). We decided to push requirement of reordering nodes to the XamlReaders of the world since that would make the XamlObjectWriter as fast as possible.
XamlXmlReader reordering
So that means that we had to push the reordering requirement into the XamlXmlReader. The XamlXmlReader will try its best at reordering as much as possible. For example, this scenario would be reordered by the XamlXmlReader:
<MyButton Background=”Red” x:FactoryMethod=”CreateInstance” Content=”Click me”>
<x:Arguments>
<x:String>Some argument</x:String>
</x:Arguments>
</MyButton>
The node stream would look something like this:
SO MyButton
SM FactoryMethod
V “CreateInstance”
EM
SM Arguments
SO String
SM Initialization
V “Some Argument”
EM
EO
EM
SM Background
V “Red”
EM
SM Content
V “Click me”
EM
EO
The XamlObjectWriter would be able to handle this fine since all the Construction directives have been moved forward. While this works for most scenarios, we can’t reorder everything in the XamlXmlReader (or rather we chose not to). If you chose to place the construction directive as the last possible property element in the object, we’d have to scan through the entire object (and all its children) before we could know how to create it. If you did this for the root object, we’d have to buffer the entire document before outputting a single XAML node. What makes this even worse is that even if there’s no construction directives, we’d still have to buffer the entire document in order to do any processing. Because of this, we chose to implement a few rules on where construction directives could appear. All construction directives MUST come before any non-constructor directive property elements. You can have non-construction directive property attributes before but you can’t have them as property elements. <Foo Background=”Red” x:FactoryMethod=”bar”/> is fine but
<Foo>
<Foo.Background>Red</Foo.Background>
<x:FactoryMethod>Bar</x:FactoryMethod>
</Foo>
is not allowed. We believe this is a far compromise between needing performance and usability.
GetObject
GetObject is very similar to StartObject except that instead of creating an object, we get the value of the parent property to use as the instance. So if the XamlObjectWriter sees SO Window, SM Resources, GO, we’ll call the getter on the Resources property and use that instance. It’s also different from StartObject in that we call the getter immediately and don’t have to wait around for construction directives. GetObject is currently only used for retrieving collections (or dictionaries) (CLR guidelines recommend that you have read only collection properties).
The rules for whether the XamlXmlReader outputs a StartObject or GetObject are pretty simple. If the first element inside is assignable to the Property, generate a StartObject. If it’s not, generate a GetObject. It gets a little more complex if the first child a MarkupExtension though. Since MarkupExtensions can return objects that could assign to property, we assume that they are value of the property. For example, in this case
<Window.Resources>
<StaticResource ResourceKey=Blah”/>
</Window.Resources>
We assume that the StaticResource will return something from ProvideValue that is assignable to the parent property. You can avoid this by either making the MarkupExtension not the first element or by putting an x:Key on it if you’re inside a Dictionary property.
