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!
Alex Norcliffe
Lead Architect, Umbraco 5