The Umbraco Foundation - A dynamic journey of concerns

The Macaw.Umbraco.Foundation is deprecated and I’am not involved in the development of this anymore. However we continue working on Muffin which is based on the same principles.

This post is a recap of a presentation I gave at the BUUG (The Belgium Umbraco User group) The presentation is available on Slideshare.

Why did I start developing the foundation?

Two of my main concerns when I dived a little deeper into the Umbraco system are:

The flexibility of Umbraco has it’s price. XSLT, Webforms, MVC where to start and what to use? I have seen solutions where all these techniques are used together. Resulting in a non-maintainable solution at the end.

I don’t like code ….. In VIEWS! How can we keep them front-end / non-Umbraco developer friendly?

For example the next line of code is very Umbraco specific:

And the next piece of code looks more like a ViewModel declaration than actual view specific code.

Let’s separate the concerns

Models are for business

Controllers are for interaction, and creating views

Views are templates where content and design come together

A great practice is “Single responsibility” or sometimes also called “Single point of failure”. Umbraco has some great solutions for that. IPropertyValueConverters for example prevent you to write a bunch of code everytime you try to convert your ContentPicker property to an IPublishedContent object. The property converter is called every time GetPropertyValue is exececuted. We have implement 4 converters in our foundation, which in our foundation also work for Macro properties (parameters).

ContentPicker returns an IPublishedContent, which usually returns an integer.

MediaPicker returns an url or a nice looking default image, which usually returns an integer aswell.

RelatedLinks returns a list of UrlModel objects, which usually returns some json (since v7).

MacroContainer returns a list of DynamicMacroModelHtmlProxies. This is a proxy for the DynamicMacroModel class and extend it with IHtmlString functionality. The DynamicMacroModel is a dynamic representation of a Macro object where the parameters are the properties. The IHtmlString functionality is the Umbraco tag for rendering the macro <?UMBRACO_MACRO .. />. Usually a MacroContainer property results in a HtmlString where all macros are merged together in one div container. Which a front-end developer don’t like because of the extra html and the Umbraco developer don’t like, because he doesn’t have any flexibility to manipulate the list. What about a Macro that looks like this?:

Simplefied views

The PropertyValueConvertes results in converted objects where you don’t have to convert those properties every time in your view. But simplified views mean a little more. And with a little I mean views with as less system dependency (like GetPropertyValue etc) as possible. In the end this can result in something like this:

But where is the “GetPropertyValue” called in the Simplefied views example?

Suprise! That’s all about dynamics. By introducing a Dynamic”View”Model every TryGetMember call can excecute the GetPropertyValue. The best of it all; Umbraco has already done this with their DynamicPublishedContent. In our foundation we just write a proxy for the DynamicPublishedContent that add some extras like: a “Homepage” property and “Breadcrumbs”. This proxy is acting as our ViewModel.

The foundation

The foundation mainly focussed on the concern of “clean” views. However the foundation is a lot more. Other important goals are:

Standarisation. By giving a set of best practices and implementation which can be used in other Umbraco projects as well.

Single responsibility. No (or as less as possible) duplicated code or implementations. This is mainly reached by doing separation of concerns right.