Easily the single most underappreciated content management system ever constructed is Umbraco, the .NET-based open source platform built by Niels Hartvig and a Danish team who present themselves as the friendliest developers on the planet. For anyone who’s ever used it, Umbraco is a Saturn V Rocket construction kit, with all the constituent parts neatly labeled but without a complete assembly manual. (There are some great videos where you can watch friendly developers build component parts, but you really need to watch them about 18 times to figure out what they’re doing.) While you can run a simple blog out-of-the-box with Umbraco, it’s as reconfigurable as Legos, but not as self-explanatory. Not nearly.
Getting out of the doghouse and earning consideration on the same level with Drupal and Joomla has required the Umbraco team to wean their platform off of XSLT – a perfectly standardized language for XML transforms that’s used by no one and loved by fewer – and onto something a bit more high-level. The team has been accomplishing that, albeit in stages, with version 4 with the adoption of Razor, Microsoft’s newer (and better) ASP.NET syntax based on C#, although Visual Basic also works quite well.
Yesterday, we learned more about the syntax of macros being developed for Umbraco version 5, codenamed Jupiter. Yes, there’s a new round of changes; no, not every Umbraco developer will welcome that fact yet again. But the result continues to be evolutionary, and on the right path.
In a new blog post, Umbraco contributor Shannon Deminick demonstrated the new class of ASP.NET macros whose cryptic name (there are plenty of cryptic names in Umbraco) is Partial View macro. Think of it as a perfected Razor macro, but with better support for strongly-typed components.
Here’s one example of a server-side macro using the Partial View construct, courtesy of Deminick:
@Html.UmbracoMacro("blah")
public Content CurrentNode { get; }
public dynamic MacroParameters { get; }
<h2>Names of child nodes</h2>
@foreach (var child in Model.CurrentNode.ChildContent().AsDynamic())
{
<p>
Child node name: <b>@child.Name</b>
</p>
}
Here you see how easily the Razor code (which is still Razor by the way, or technically a .CSHTML file) co-exists with the markup code. Although this is actually a throw-away component that does less than your average “Hello, world,” you see the basic structure: The @HTML header starts things off now. There’s strong typing by way of variables that represent where the current node is in the database tree (an article in an Umbraco folder is one example of a node) and the parameters being passed to the macro, which may number from zero to a handful. (According to a recent addition to the Umbraco wiki, “Depending on the macro chosen, we will hopefully be able to dynamically populate the macro parameters instead of having to manually type them in like in v4.”) Note the Content data type, which is an indicator of how Razor uses dynamic typing here.
The foreach loop uses a C# construct, which is a simplified way to say “for all elements of a list” without creating an iterator variable like in C++. Just like in Umbraco v4, the @ acts as a type of switch, telling the parser, “I’m not talking to you in HTML for the moment, I’m switching to Razor.”
“Razor views allow you to define public properties, methods, etc. inside of the Razor markup,” writes Deminick. “So if we want to have strongly typed parameters for our Partial View Macros which can be set based on Macro parameters in [Umbraco’s] rich text editor, all we have to do is declare them.”
What does this mean, really? Modern CMS packages are limited in terms of the types of functionality they enable. As a result, blogs tend to act like all the other blogs. When you’re running a blog, and you can’t have an article stored in one department access an image that was added to the still store via an article in another department, that’s a database design issue created by the makers of the CMS. And it’s those people who have to solve the issue; until then, you’re stuck.
You are never stuck with Umbraco if you know what you’re doing. Enabling an image to be just as accessible through an article on one tier of the tree (one node in Umbraco) as it is from another node, is a matter of developing the tree architecture right to begin with. And if you’re the one doing it, it suddenly becomes a possibility.
The latest community technology preview of Umbraco v5 (which does not have the latest enhancements yet) is available from Codeplex.
