ProWorks Blog

Here's some handy info that can help you get started with the switch-over from the Umbraco Masterpages to the new Views.

Check out Umbraco's Cheat Sheet

First of all, check out this nifty cheat sheet from Umbraco. There are a few typos, but it's definitely helpful to have around.

The @Section should be lowercased. If you uppercase it, it will not work.

@Section BodyElement{
    <p>Hello</p>
}

@section SidebarElement{
    <p>Hello</p>
}

@RenderSection default content

In the old <ContentPlaceholder> syntax, it was really easy to specify the default content of a ContentPlaceHolder:

<asp:ContentPlaceHolder Id="innerContent" runat="server">
    <umbraco:Item field="bodyText" runat="server" />
</asp:ContentPlaceHolder>

In the new View system, this is a little more tricky.

@If(IsSectionDefined("innerContent"))
{
    @RenderSection("innerContent")
}
else
{
    @CurrentPage.bodyText
}

You need to be careful with the @RenderSection function. If you call something like

@RenderSection("headerScripts")

and the child view does not provide a

@section headerScripts{

}

everything will explode. If you aren't completely certain that every single child view will provide the @section, you should call @RenderSection as follows:

@RenderSection("headerScripts", false)

Page property default values + recursion

We had a situation the other day where a page's heading would be the node's Name in most cases but in some cases needed to be manually specified. In masterpages, we did this:

<umbraco:Item field="pageHeader" useIfEmpty="pageName">

Now, we do things like this

@Umbraco.Field("pageHeader", "pageName")

OR

@Umbraco.Field("pageHeader", altFieldAlias: "pageName")

You can also set the property to be recursive like so:

@Umbraco.Field("pageHeader", recursive: true)

Handling Partial Views

For those of you new to the MVC way of things, here's a really basic example of partial views:

In one of your Views, you might call:

@Html.Action("RenderTestForm", "TestSurface")

This calls the RenderTestForm method of a TestSurfaceController that I wrote. Let's take a look at that SurfaceController.

[ChildActionOnly]
public ActionResult RenderTestForm()
{
    return PartialView("TestForm", new Models.TestViewModel());
}

That method renders the PartialView called TestForm. Let's take a look at TestForm:

@model TestProject.Models.TestViewModel
@using TestProject.Controllers.SurfaceControllers;

@using (Html.BeginUmbracoForm<TestSurfaceController>("HandleTestActions", new { returnNodeId = 1146 }))
{
    <!-- Rendering the test form here -->

    @Html.TextBoxFor(model => model.SomeProperty)

    ...
}

This PartialView is rendering a form that will be submitted back to the HandleTestActions method of the TestSurfaceController. In this scenario, the TestViewModel is being implicitly passed to the HandleTestActions method. If you want to pass more parameters, you have to do it manually. In the above example, we are passing an additional parameter, returnNodeId. Let's take a look at the TestSurfaceController again.

[HttpPost]
public ActionResult HandleTestActions(Models.TestViewModel model, int? returnNodeId)
{
    // doing something interesting here
    ...
	
    // redirect to a Success! page maybe?
    if (returnNodeId != null)
    {
        return RedirectToUmbracoPage(returnNodeId.Value);
    }
    else
    {
        return RedirectToCurrentUmbracoPage();
    }
}

You can see that the TestViewModel was being passed into the HandleTestActions method as well as the returnNodeId.

Partial View Macro Files

These are pretty simple. With Partial View Macro Files, we can wrap our PartialView in a Macro. What usually happens to me is that I'll write my SurfaceController and my PartialView, but instead of calling it from my View, I'll write a Partial View Macro File and call

@Html.Action("RenderTestForm", "TestSurface")

from there. Now I can do things like put parameters inside of my macro or even call the partial view from within a richTextEditor if I so desire.