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!