One of the features I spent a lot of time thinking about, and implementing are: “deferred” ProvideValue calls on MarkupExtensions. In a XAML markup extension, ProvideValue is called when the tree is being loaded, and sometimes, it may be impossible to provide a value at that time. Also, since XAML makes use of internal classes like ResourceReferenceExpression (along with some other quirks like requiring derivation from FrameworkElement. More on this here), it becomes quite a messy task resolving these references and values later.

In Xoml, however, every markup extension can tell XomlLoader to defer its ProvideValue call, by setting defer to true.

public abstract object ProvideValue(object context, PropertyInfo property, out bool defer);

Of course, at this point the markup extension is also expected to provide a default value, one that can be assigned to the context without errors. It is important to remember that the “context” can also be other markup extensions, in the case of a nested sub-expression.

After the entire object tree has been loaded, DeferredProvideValue

public virtual object DeferredProvideValue(object root, object context, PropertyInfo property)

is called once for each ProvideValue call that was deferred. Since the tree has been loaded now, the partially-initialized(?) root object is also passed in. XomlLoader then calls the OnAfterLoad method on each markup extension that was found.

protected internal virtual void OnAfterLoad(AfterLoadEventArgs e)

This calling order is undefined, and extensions that have not been used in the currently loaded XOML are not called upon for OnAfterLoad processing. OnAfterLoad is called exactly once for each type of extension, its calling order is undefined. Like DeferredProvideValue, the root of the tree is provided to this method. The difference here, however is that OnAfterLoad can return a different object back to XomlLoader (through AfterLoadEventArgs), thus changing the whole tree! I’m not sure if this is an irresponsible thing to do, I thought it might help do radical things to the object tree and make it more extensible.

I would love to hear your thoughts on the features I’ve currently implemented, and future directions for development.

For a long time, I’ve been writing about how messed up Xaml is because of WPF-interdependency, and how Microsoft should have decoupled the Xaml bits from WPF, etc (Some of these rants were on my old blog). Well, I finally decided to do something about it, and I’m writing a XAML-like library that loads, and writes markup using its own XomlLoader and XomlWriter. At this point I’m calling the markup eXtensible Object Markup Language (I know that the Workflow Foundations’ designer files have that extension…) because that’s what its meant to be. It is also aimed to run on the .NET Framework, Mono and the .NET CF.

Using Xoml, you will be able to data-bind, forward reference, resource reference, write markup-extensions and more. I will be putting this project up for download shortly, look out for more news on it.

PS: If there’s enough interest, it will have its own mini-site here!

It’s great that you can reference other objects in a resource dictionary in a XAML file. This makes it particularly interesting to me, since I go the whole hog and almost everything is a resource. For example, in my application (its a sort of scene graph), textures, materials and even animations are resources which other objects can reference. This makes things easier for me, allowing one instance of a potentially costly resource (like a large texture, or a vertex/pixel shader) to be used by multiple consumers. I suppose the same example could be applied to other cases as well. Resource sharing is a good thing, period. Well … this comes with its own set of problems with Xaml. Unless you hand-write all the XAML, StaticResource is practically useless unless you are guaranteed to have no forward references. This is understandable, and even the MSDN documentation says so quite clearly. The alternative is to use DynamicResource to resolve these references. Or so it says.

Trying it out, it seems that DynamicResource returns an internal class, ResourceReferenceExpression from ProvideValue, which is a way to tell the XAML parser to defer resolving this expression. But how and when does the expression actually get resolved? Its supposed to be resolved the first time its accessed, which unfortunately doesn’t seem to be the case. The resolving part seems to be tied down to a method (GetRawValue) that assumes the objects are derived from FrameworkElement. It also seems there’s no way to do any of this yourself since almost everything of any value is internal or sealed. All’s not lost, however, since DynamicResource is not sealed . See, while we could very well write a custom markup extension, its ProvideValue would have to return null when XamlReader invokes it. This is a problem, and many objects won’t work properly when we do this. The alternative is to derive from DynamicResource, and return base.ProvideValue which is a ResourceReferenceExpression. At the same time, we note down the resources that require resolving in a static table. We can then use this table after the load to resolve all references. Attached is a VS2008 project that implements a ResourceExtension markup extension. There are some limitations to the code I’ve written, for example: it doesn’t take care of a resource reference that references another. For this ,we need to resolve in a particular order. But you get the idea, right?

So far, there’s no mention of how to write expressions to a XAML file. XamlWriter just wont do, since it will write the value of the property, and not the expression used to calculate it. Next time, we’ll talk about some a custom XamlWriter and some problems in that context.