So long, XML
Wednesday, January 21, 2015 5:43 PM umbraco
One of the reasons for the success of Umbraco is probably that rendering pages is fast and that, in turn, is due to all content being cached in memory at all time. Navigating and rendering content do not hit the database.
That memory cache has always been composed of one big XML document representing the whole content tree. That was fine, because content was hierarchically organized, and it allowed for fast and easy processing of the whole tree with XSLT—which was the only way to render content.
And then things started to evolve.
- Microsoft introduced MVC and Razor, and some people considered it would be a good alternative to XSLT (though it is still a debated subject)
- Content evolved and began to become more and more tabular and relational, and to outgrow the strict structure of the tree (see What becomes of XSLT)
- Some issues with having one big XML document started to become more pressing, such has concurrency or preview management
However, the whole rendering layers of Umbraco were built on top of the XML cache, and the XML cache was everywhere, and so it was difficult to just start thinking about changes... without breaking everything.
So for some time now, work has been in progress in the dev-v7-contentcache branch to isolate the "content cache" into a component with a well-defined contract or interface, so that it later on becomes possible to think about different implementations of that cache.
Today's Progress Status report
As of Jan. 21st, 2015, this blog is dogfooding the dev-v7-contentcache branch. The cache implementation that is used is still the XML cache, but it is entirely abstracted and lives in one well isolated component (
Don't get too excited, it is not ready for production—but it works. Some work remains, in order to ensure that the cache is properly refreshed when "things" happen to content or to content types. And then, it needs to be heavily tested.
But we're getting closer, and already have a POC full-object-oriented cache that should land in the Git branch soon.
The cache contract
So... this is the death of XSLT, right? Not quite.
Sure, the big central
XmlDocument instance does not exist anymore—in fact, the whole
content class is gone. But the cache contract specifies that a content cache must be
IXPathNavigable—in other words, that whatever the implementation, it is possible to invoke
cache.CreateNavigator() and obtain an
And this is all the .NET Framework needs to execute XSLT transforms or XPath queries. The dev-v7-contentcache branch also contains a cache implementation,
PublishedNoCache, that basically does not cache anything and hits the database for every content. Obviously, it is insanely slow, but it runs XSLT macros quite fine.
Want to get ready for the future? In most cases, all you have to do is to stop thinking "
XmlDocument" and start thinking "
XPathNavigator". So, no more:
var xml = content.Instance.GetXml();
But (in all v7 versions already):
var nav = UmbracoContext.Current.ContentCache.CreateNavigator();