Umbraco 5: May the blogging commence
Over the past few years I've talked to a huge number of people involved in Umbraco in one capacity or another. Despite the variety of ways in which people are connected to this CMS - as an editor, an implementer, a package developer, a contributor, a business owner - what has shone through is how there's a great admiration for the system. For all its quirks, Umbraco has made a great many people's jobs easier - and that's a heritage of which we're immensely proud.
Of course, although like all parents we'd like to think our baby is the best, the reality is it's not perfect - it's software - and some time ago with the advent of ASP.NET MVC we saw an opportunity to address some of these quirks in a way which would give the platform a new lease of life. Umbraco has been going six years, not much less than .NET itself, and it would be great to give it a shot in the arm so it can catch up with some of the technologies which have sprung up around it.
Enter Umbraco 5, or Jupiter as we call it. We've been talking about it for some time, at CodeGarden 10 and various other Umbraco festivals, and it's exciting to say that we're not far from being able to drop some of the code onto CodePlex.
To accompany this, over the next few months we'll be blogging about our progress as well as some of the architectural scaffolds which we've put in place.
In this first couple of blogposts I'd like to cover a few things to give you a taster of what's to come, to set the tone for later when we'll be talking in more technical detail. First, for those who haven't seen either of the talks I've given this year, what follows is an introduction to the project and our motives. I've then followed up with a second post which starts a Q&A series. I won't be the only blogger of course - you'll see posts from Shannon Deminick and Aaron Powell and no doubt many others as we progress.
"So I hear you started from scratch…?"
I think it's safe to say that a whole load of developers have, at one point or more, written a "CMS". Personally that's how I started my career, but it wasn't some idealistic vocational dream - I just wanted to ensure I didn't personally have to do every last text edit on my client's website. It's one of those areas where the often tempting effort to engineer a "cool" solution to avoiding finicky coding is actually worth it - it's not just about avoiding repetitive work for us lazy coders (although that was my initial reason): at the end you've given your customer, the real content expert, a much better experience and greater freedom of expression.
But there's a point where every back-office developer stops and thinks: "I've done this before." It's what inspired Niels to start Umbraco in the first place, as was the same with me, and doubtless the same with most outfits which decide to build a CMS product.
One thing to make clear, though, is that Niels reached this point many years ago: what we have today is the result of the momentum he and the community created around that moment. Whilst it's true that we have literally started from a blank codebase with 5, we've no need to start from scratch on the whole idea: Umbraco has had the beneficial input of literally thousands of talented people over many years. Our aim in 5? Simple: give you an Umbraco which feels familiar, makes you feel just as constructive, but knowing that you can take advantage of the latest advancements in the .NET technology stack on which we all thrive.
Blank codebase vs progressive enhancement
Some would (and have) argued for a progressive enhancement of the existing code in order to get there. But there comes a point where you've replaced so many parts of the car that you're left only with the original chassis, and you have to attack that problem if you are to make fundamental improvements.
In fact, this approach leaves us with a tangible benefit: as you may have seen, we've got a 4.6 release due in the next few weeks. Adding the kinds of sugar to the product on a quick release cycle is only possible precisely because we're developing 5 in parallel. As we've often said, the two will co-exist for a long time to come - so there's no need to worry about opting for version 4 today.
What makes Umbraco… Umbraco?
After so many years of iterative development, it's difficult to list every single piece of the system out of the gate. There are doubtless some features which only a handful of people use, but which we want to keep for the future, so an important task for us was to define the important chunks to include in the first release of 5.
In order to keep a level head we've drawn from a huge gamut of installations to get a feel for how the product is used. I wanted to be careful that the current "80% scenario" was not blindly trusted: in some cases, our install base is defined not just by the features and the desire but by Umbraco's current limitations - and we want to address those where possible in 5.
Given your level or type of experience with Umbraco the terms may be familiar - document types, document properties, data types, macros - but we actually compiled all this into a single document (for the first time!) earlier this year to make sure we were keeping on track.
The result of the analysis is that we have drawn up an architecture which is capable of representing these same features, but with similar objects and approaches merged into more useful abstracts.
In any software system, the greater the re-use of code, the more robust it can become and the easier it can be to find and fix bugs. And so, in Umbraco 5, our deepest layer of abstraction is actually kept entirely separate and reusable: we will be shipping a Framework, on top of which the CMS is built.
Goals of the new codebase
The ultimate necessity is that it feels like Umbraco, but specifically here are some of our goals with this project:
- Increase the quality and testability of the codebase
- Increase the level of extensibility to the core components
- Use the MVC paradigm for rendering
- Adhere to a greater number of accepted software engineering patterns and practices
- Make more of the drastic improvements in the .NET space since Umbraco first shipped
- Increase scalability, and add better performance monitoring and logging
- Ensure it's just as easy to use - if not more so - than the current version
Where it's at
The core team first discussed the project in summer 2009, but with 4.5 in the works we didn't form a focus group until March 2010, after which I spent some time on the analysis and initial architecture sketches. We kicked off in earnest in September 2010, and since then we've made great progress adding flesh to the bones - thanks in no small part to Shannon Deminick and Aaron Powell who are amongst the best lead devs anyone could want. We've been coding in a private repository for a little while but we'll be moving active development over to the CodePlex repo pretty soon. Here's how it's shaping up:
- ASP.NET MVC 3 and Razor view engine: We're very lucky to have a release schedule that is aligned with this brilliant new view engine. It's been a tough challenge to build on top of something still under active development, but we could see early on that the effort was going to be worth it. Phil Haack, Eric Porter and others from Microsoft have done a great job of helping out with answers to some of our more inane questions.
- Dependency injection: Umbraco is known for being a very extensible CMS already, but 5 takes this to the next level by using IoC for the invocation of each component. We're using AutoFac for much of the "commodity" dependency resolution, and at the moment we're also experimenting with MEF for some areas such as DataType assembly loading.
- Data persistence: In Umbraco 4, whilst we offer a few choices of database provider, the abstraction isn't flexible enough for you to truly "roll your own" without having to do a custom build of the sourcecode. In the 5 Framework, we've specified the various data models on which the 5 CMS and rendering pipeline run, and data persistence is essentially a case of writing a few repository providers abiding by the contracts set out in the Framework. Out of the box we'll ship providers for the usual suspects - SQL Server, MySQL, etc. - including SQL CE 4.0 of course. But as I'll explain in a subsequent post, you'll see there really is no reason why you couldn't have a provider that ran off something entirely custom.
What's to come? Feature teasers
There's not enough space in one post to cover everything exhaustively, and in fact we're still in active development, so this series will expand as we continue our work. To whet your appetite, here are a few of the headline points about what's coming in 5:
- Entity Hive: in the typical content tree in 5, children of one content node can contain nodes from a different node provider. For example, if you require your own Comments database entities represented 'underneath' Content nodes which are from the out-of-the-box repository, Hive stitches that together for you.
- Native cloud support: our file storage mechanism is of course abstracted - natively load files from Amazon S3, Azure Blob Storage, or - shocker - the local filesystem.
- Compiled datatypes and their associated views: currently Aaron is looking into using MEF for assembly resolution here.
- Integration with MVC3's standard model binding and validation against the document model and individual datatype models.
- Complex models at the DataType / document property level: Should you want to write a DataType which contains multiple fields, you can still rely on the standard model binding and validation provisions.
- Read-fast and Read-write repositories, aka running natively from Lucene: easily separate the very different performance tradeoffs that the render pipeline needs, from the back-office, within the one application. We'll be shipping a read provider which gets entities from Lucene so you can run your site from this extremely fast store whilst choosing for the back-office to save natively to a different provider such as SQL Server.
I hope this serves as a useful introduction to where we're headed with 5. In the next post, I'm kicking off our Q&A session series, and then after that I'll open the lid on some technicalities around Hive.
Thanks for reading!
Lead Architect, Umbraco 5