Where we left off
In the first installment, we explained what Razor was, set up our development environment, downloaded the MVC 3 preview and looked at the contents of the default project. We then took a look at the structure of a content view file using the Razor view engine and compared it to a content view file build with the standard aspx view engine. We also looked at some of the features in MVC 3 which are enabled by use of the .Net 4.0 framework to allow us to better express our intentions in view.
In this installment, we will now look at the master page view in Razor and examine how it differs from the standard aspx master page view. We will also start investigating the scripting syntax provided by the Razor view engine in more detail.
Back to work!
As a first step, open up the project we created in the last installment. It is simply the default project generated by Visual Studio 2010 for the ASP.Net MVC 3 framework. As you may recall, we looked at a sample view page, index.cshtml. Now, we are going to look at the master view page.
Layout Files
When using the Razor view engine, the term Master page isn’t used as often as in the aspx view engine. Instead, these pages are referred to as layout pages because they provide the general layout for the page. It is the same basic concept as a master page, but a bit more flexibility is available to us, particularly with regards to marking regions of the page as optional (more on this later). The default layout page generated is called _Layout.cshtml and contains the following code. For the sake of readability I have elided part of the doctype declaration.
1: @inherits System.Web.Mvc.WebViewPage
2: <!DOCTYPE html PUBLIC … DTD/xhtml1-strict.dtd”>
3: <html xmlns=”http://www.w3.org/1999/xhtml“>
4: <head>
5: <title>@View.Title</title>
6: <link href=”@Url.Content(“~/Content/Site.css”)” rel=”stylesheet” type=”text/css” />
7: </head>
8: <body>
9: <div>
10: <div id=”header”>
11: <div id=”title”>
12: <h1>My MVC Application</h1>
13: </div>
14: <div id=”logindisplay”>
15: @Html.Partial(“_LogOnPartial”)
16: </div>
17: <div id=”menucontainer”>
18: <ul id=”menu”>
19: <li>@Html.ActionLink(“Home”, “Index”, “Home”)</li>
20: <li>@Html.ActionLink(“About”, “About”, “Home”)</li>
21: </ul>
22: </div>
23: </div>
24: <div id=”main”>
25: @RenderBody()
26: <div id=”footer”>
27: </div>
28: </div>
29: </div>
30: </body>
31: </html>
Line 1 indicates our parent class. As noted in the last installment, this is different than the base class used in the aspx view engine. Notice that once again in line 5, we use @View.Title to allow us to replace the title with a value supplied by the individual view. Notice in line 6 we include our css file but we use Url.content to properly find our file. Also notice the use of @ to indicate that this is server side code.
Until line 15, we are looking at good old fashioned html. It’s nothing unusual. Line 15 contains the line
@Html.Partial(“_LogOnPartial”)
This is our first look at using a partial view. Instead of using RenderPartial or RenderAction, we use the Partial html helper. @Html.Partial. As with partial views, this effectively includes the contents of the partial in our page. Again, notice the convention of leading the name with _. Convention is always very important in Asp.Net MVC as convention is responsible for many defaults.
As noted previously, helper functions work the same as in the asp.net view engine. Only the syntax is different, with @Html… replacing <%:…%>. Finally, on line 25 we come to the most important part of the layout page. @RenderBody() is what tells the layout page where to insert the view’s content.
Note that in our view page, we must reference the Layout page explicitly to link the two pages. So that is a quick overview of the default Microsoft template. But there is considerably more we can do with layout pages. Like the aspx view engine, we can have multiple templated areas with our layout page. The difference is that with the razor view engine we have the ability to indicate whether or not a section is required.
To define a section in your layout page, you use the following syntax:
@RenderSection(“NewSection”)
This indicates that the view page MUST include a section named “NewSection” or bad things will happen. However, if you use the syntax:
@RenderSection(“NewSection”, optional:true)
Then it works out just fine. Similarly, using:
@RenderSection(“NewSection”, optional:false)
In my opinion, it is well worth your time to explicitly state the optionality of the section in either case. It just makes it that much more clear for developers implementing views that utilize the layout page to see what they need to provide.
Now, to make use of this new section in the view, we simply wrap the section in the view as if it were a code block. For example:
@section NewSection
{
<a href=….
}
Now, if you’ve paid close attention up to this point, it will occur to you that RenderBody doesn’t require a @section block. RenderBody is a special case and doesn’t require an identifying block, as the entire view can be thought of as the body.
So, @RenderBody determines placement of the view as a whole and @RenderSection controls rendering of sections within the view. Since we can mark sections as required or not, we can do things like create layout pages with optional footers or headers. Here is an example of a very clean layout page which is pretty flexible:
@inherits System.Web.Mvc.WebViewPage
<html xmlns=”http://www.w3.org/1999/xhtml“>
<head>
<link href=”@Url.Content(“~/Content/Site.css”)” rel=”stylesheet” type=”text/css” />
</head>
<body>
@RenderSection(“Header”, optional:true)
<div id=”main”>
@RenderBody()
</div>
@RenderSection(“Footer”, optional:true)
</body>
</html>
It’s very simple and very clean! Now, a view that uses this might look like:
@inherits System.Web.Mvc.WebViewPage
@{
View.Title = “Home Page”;
LayoutPage = “~/Views/Shared/_Layout.cshtml”;
}
@section Header
{
<h1>Header</h1>
}
<p>
Body
</p>
@section Footer
{
<h1>Footer</h1>
}
Again, this is very straightforward. Also, since the sections are named, they do not have to match the ordering in the layout page. It is perfectly okay to have all your sections at the end of the file for instance.
Summary
In this installment, we’ve reviewed layout pages and all the fun stuff they enable us to do. In the next one, we will take a look at partial views as well as control structures. Lots of fun stuff!
No Responses to “Rolling with Razor in MVC v3 Preview – Part 2”