The last part of the Umbraco 5 Gems talk at CodeGarden 11 was to
look at some of the more crazy aspects of Umbraco 5, the stuff that
you'll want to know if you're delving deeply into the API and
really wanting to extend Umbraco beyond the needs of the average
user.
IoC is swappable
We've decided that Autofac will be our IoC (Inversion of Control)
container of choice, but that doesn't mean that it suits everyone.
As a developer you might already have a stack that relies on
another library such as NInject or Windsor, or your team is just
more comfortable with one of the other DI containers
available.
With the way the Umbraco 5's IoC is designed it will be possible
for you to use another IoC container without having to hack into
the core of Umbraco, instead there will be a few interfaces and
classes to implement which will provide all the hooks into Umbraco.
Internally all of v5's dependency registrations are done against
our abstraction layer meaning as soon as you plug in your library
of choice, our registrations will still end up in your container
for you to interact with or have our components injected into
yours.
Abstract task system / loosely-coupled events bus
In Umbraco 4 events are strongly typed against the various .NET
types within Umbraco, using the standard .NET event system. In an
application the size and complexity of Umbraco standard .NET events
can be a bit restricting, so instead for Umbraco 5 we're going with
a loosely coupled task system in which events are raised into an
application-wide task manager based on pre-defined trigger
names.
To listen for a task you simply hook your code up with a trigger
name similar to a regular .NET event, or add a Task to your plugin
assembly decorated with the appropriate attribute, and our task
manager will execute it when the relevant trigger is fired, meaning
you don't have to connect directly to a particular object instance.
Tasks are also chainable so you can cancel proceeding tasks or pass
information back to the caller or the next task in the queue.
It also means that a task with a particular name can be raised
from various locations within the application - even your own
plugins.
This disconnected task system means that we can have much greater
flexibility than standard .NET events.
File system is a Hive provider
Like everything in Umbraco 5 we have a Hive provider for the
file system. Files such as CSS, JavaScript, Templates, etc are
loaded through the Hive. Out of the box this will be loading off
your hard drive, but it does mean that we have a lot of interesting
options. Since we abstract away the file system you can swap the
file system out for a Hive provider for one which reads out of a
database?
Or out of cloud storage like Azure?
This means that you can leverage the power of a CDN to serve out
your common assets and increase the scalability of your Umbraco 5
website.
Drumroll... Umbraco Application Framework is separate from the
CMS
Since there's lot of cool features and reusable classes in Umbraco
5 which don't require a web UI, or any UI for that matter, we've
made a deliberate separation between the Application Framework and
CMS projects and because of this you can use them without the CMS
product itself.
In fact the CMS is just a product which has been built on top of
the Umbraco Application Framework.
So in your own application you can leverage APIs such as the Hive,
Localization or the task system.
So this wraps up the list of Umbraco 5 Gems from the CodeGarden
11 talk but as it turns out there was way too many Gems to cover in
a single hour so keep an eye out for the next post on the Umbraco 5
Gems we haven't previously spoken about!