My first real take-away is that it is simply a brilliant enhancement to embedding display code into your views. With the markup being clearly distinguishable from both HTML and JavaScript, the code is far more readable.

The traditional web forms bracket-style notation, originally inherited from classic ASP and in-line with the de facto standard of the day when embedding server-side code into HTML certainly served its purpose, but it quickly becomes apparent that it doesn’t produce the most readable code.

See Razor:

<a href="@Url.Action("Index", "Home")">
    <img src="@Url.Content("~/Content/Images/logo.png")" alt=
        "Logo" />
</a>

Versus Web Forms:

<a href='<%= Url.Action("Index", "Home") %>'>
    <img src=
        '<%= Url.Content("~/Content/Images/logo.png") %>'
        alt="Logo" />
</a>

Thus, the Razor engine solves this problem and makes the front-end code easy to read and distinguish between HTML, JavaScript and server-side, embedded code.

There are five main pieces to understand about Umbraco:

• Document Types (held in the database)
• Macros (information is held in the database, but they live in usercontrols)
• Fields (held in the database)
• Templates (found in the masterpages directory)
• Pages (held in the database)

A page is what you would expect – a page that can be created in the CMS (in the Content section, right-click and Create). When you create a page, it has to be a certain document type. A document type can have one or more templates that can be used with it (the user has a choice) and different fields that can be filled out to be used on the front-end (text, images, etc).

In a template, you can choose which fields are displayed in the html (see areas like <umbraco:Item Field="text" stripParagraph="true" runat="server"></umbraco:Item> and [#text]).

Macros are really just custom user controls that can come in a variety of forms, for example a custom .Net control and can be added to a template like this:

<umbraco:Macro Alias="MyWidget" runat="server" PassedValue="[#value]" SomethingElseToPass="true"></umbraco:Macro>

These function as normal custom user controls (code-behind, etc). To get Umbraco to pass values (like “value”), you need to add that information about the macro under the Development section.

The database structure is not very clear, and I generally try to avoid it so I don’t mess things up. Another note is that Umbraco cannot be run in a virtual directory, so to do development, you need to set it as your root website.

So, in short, a Page has a Document Type, which gives a user a set of Templates to choose from and Fields to fill out, and the Template determines how those Fields are displayed and if/what Macros are used.

1. Umbraco cannot be run in a virtual directory.

This definitely becomes obvious after trying to install it, but was certainly the first hiccup I had with Umbraco. Certainly not a deal-breaker, and when combining that with Helicon Tech’s ISAPI_Rewrite, ended up not being a problem in the slightest.

2. Umbraco’s document/database structure is non-obvious.

I definitely think the engineers over there are bright and did it the right way – it was just a more complex and abstract system than I was initially expecting. I don’t think it’s something they need to work on changing, but it was another hiccup I went through when I first started using Umbraco.

3. Umbraco creates a cache of pages when they are published.

When a page is called in Umbraco, most of the result is served directly from a cached XML file. Certainly was a great call performance-wise and makes sense, but it was not something I realized when I first set out with Umbraco.

4. Umbraco is simply incredibly powerful.

While all of the above might seem like I have reservations about Umbraco. In fact, quite the opposite. Sure, there were bumps in the road as I went along, but in the end, I came out liking Umbraco more and more as I got to know it better and use it more. It’s incredibly powerful and useful, from the template creation to embedding macros. Making changes and updates is far easier than I would have imagined and I cannot thank the Umbraco team enough.

You don’t want a bunch of commented out sections of the config, that would be annoying, and you’d have to change them based on the environment.

What I like to do is rename the config based on the environment. So you can have you Web.dev.config, Web.qa.config or Web.production.config or similar. Simple as pie! Sure maybe there are more files in svn, but you only have to remember to rename the file when you deploy (or have it be part of your automated deployment procedure), which is definitely easier than working within the file itself.