ASP.NET MVC 2 includes support for strongly typed HTML helpers, which allow you to specify Model properties using a Lambda expression rather than as strings. For example, where you would have previously used <%: Html.TextBox("PropertyName") %> in ASP.NET MVC 1, you can now use <%: Html.TextBoxFor(m => m.PropertyName) %>. Replacing strings with expressions provides a number of benefits, including type checking, IntelliSense, and simpler refactoring. We'll point out which HTML helpers have added strongly typed overloads as applicable in this section.

Encode is not an extension method but a proper method of HtmlHelper. It's really a shorthand way of calling the HttpUtility.HtmlEncode method, but with the benefit that it contains a convenience overload that accepts an object, unlike HtmlEncode. When an object is supplied, it is converted to a string by using CultureInfo.CurrentCulture, before being encoded.

ASP.NET 4 includes an even simpler syntax for HTML Encoding content in a View, using the new <%: %> syntax.

The TextBox helper renders an input tag with the type attribute set to text. This is one of the form helpers most commonly used to accept free-form input from a user; for example:

<%: Html.TextBox("name") %>
Code snippet 6-14.txt

results in:

<input id="name" name="name" type="text" value="" />
Code snippet 6-15.txt

Like most form helpers, it looks in the ModelState and ViewData to obtain its current value. For example, here's one way to set the value of a product's name in a form:

public ActionResult Edit(int id) {
  var product = new Product {Name = "ASP.NET MVC"}

  ViewData["Name"] = product.Name;

  return View();
}
Code snippet 6-16.txt

and in the View you can use a textbox to display that value by giving the TextBox helper the same name as the value in the ViewData:

<%: Html.TextBox("Name") %>
Code snippet 6-17.txt

which results in:

<input id=" Name" name="Name" type="text" value="ASP.NET MVC" />
Code snippet 6-18.txt

A ViewData lookup can also look up properties of objects in the View Data. For example, going back to the previous example, let's change it to add the whole Product to ViewData:

public ActionResult Edit(int id) {
  var product = new Product {Name = "ASP.NET MVC"};

  ViewData["Product"] = product;

  return View();
}
Code snippet 6-19.txt

You can use the following code to display a textbox with the product's name as the current value:

<%: Html.TextBox("Product.Name") %>
Code snippet 6-20.txt

which results in:

<input id="Product_Name" name="Product.Name" type="text" value="ASP.NET MVC" />
Code snippet 6-21.txt

If there are now values matching "Product.Name" in the View data, then it attempts to look up a value for the portion of the name before the first dot, "Product", in which case it finds a Product instance. It then evaluates the remaining portion of the name "Name" against the product it found, yielding the value.

One other thing to note is that the id of the attribute replaced the dot in the name with an underscore. This behavior is controllable via the static HtmlHelper.IdAttributeDotReplacement property. This is necessary because dots aren't valid in an ID, and JavaScript libraries such as jQuery require valid ID's.

The TextBox helper also works well against strongly typed View data. For example, given the following Controller action:

public ActionResult Edit(int id) {
  var product = new Product {Name = "ASP.NET MVC"}

  return View(product);
}
Code snippet 6-22.txt

you can supply the TextBox helper with the name of a property in order to display that property:

<%: Html.TextBox("Name") %>
Code snippet 6-23.txt

which results in:

<input id="Name" name="Name" type="text" value="ASP.NET MVC" />
Code snippet 6-24.txt

The TextBox helper allows you to supply an explicit value and avoid View data lookup if you wish. For example:

<%: Html.TextBox("Name", "ASP.NET MVC") %>
Code snippet 6-25.txt

produces the same markup as the previous example.

If you wish to specify HTML attributes, you'll need to call an overload that also supplies an explicit value. If you want to use View data lookup in these cases, just pass in null to the TextBox helper. For example:

<%: Html.TextBoxFor(m => m.Name, null, new {@class="lotsofit"}) %>
Code snippet 6-26.txt

will result in:

<input class="lotsofit" id="Name" name="Name" type="text" value="ASP.NET MVC" />
Code snippet 6-27.txt

The strongly typed equivalent of Html.TextBox is Html.TextBoxFor. It supports the same overloads demonstrated above, so we could replace the above call with the following code:

<%: Html.TextBox(m => m.Name, null, new {@class="lotsofit"}) %>
Code snippet 6-28.txt

The ActionLink method renders a hyperlink (anchor tag) to another Controller action. This method uses the Routing API under the hood to generate the URL. For example, when linking to another action within the same Controller used to render the current View, you can simply specify the action name:

<%: Html.ActionLink("Link Text", "AnotherAction") %>
Code snippet 6-29.txt

This produces the following markup, assuming the default routes:

<a href="/Home/AnotherAction">LinkText</a>
Code snippet 6-30.txt

You can specify a Controller name as the third argument to link to an action of another Controller. For example, to link to the AccountController.Withdraw action, use:

<%: Html.ActionLink("Link Text", "Withdraw", "Account") %>
Code snippet 6-31.txt

Notice that you specify the Controller name without the Controller suffix. You never specify the Controller's type name.

In many cases, you have more route parameters than you need to supply in order to choose the correct URL to render for the action link. In that case, you can specify a RouteValueDictionary for the routeValues argument. The following example uses the overload that accepts the anonymous object overload for route values to specify the ID:

<%: Html.ActionLink("Link Text", "Withdraw", "Account", new {id=34231}, null) %>
Code snippet 6-32.txt

To specify HTML attributes, provide a value for the htmlAttributes argument. This accepts an IDictionary<string, object>, but for ease of use, you can call the overload that accepts an anonymous object:

<%: Html.ActionLink("LinkText", "About", "Account", null,
new {title="withdraw from account"}) %>
Code snippet 6-33.txt

The ActionLink methods have specific knowledge about ASP.NET MVC Controllers and actions. Hence, these methods provide convenient overloads that allow the specifying of a controllerName and actionName directly.

The RouteLink methods follow the same pattern as the ActionLink methods but also accept a route name and do not have arguments for Controller name and action name. For example, the first example ActionLink shown previously is equivalent to the following:

<%: Html.RouteLink("Link Text", new {action="AnotherAction"}) %>
Code snippet 6-34.txt

The BeginForm method follows a different pattern from the other helper methods. An HTML form generally starts with a <form> tag, contains a bunch of markup in the middle, and then ends with a closing tag.

It wouldn't be very useful to have to specify the markup that goes in between the form start and end tags to the form helper method. Instead, the method uses the disposing pattern to denote the scope of the form.

An example should clarify what we mean:

<% using(Html.BeginForm()) { %> <! --  <form ...> tag here // -- >

  <label for="firstName">
  <input type="text" name="FirstName" id="firstname" />
  <input type="submit" value="Save" />

<% } %> <! --  End </form> tag here // -- >
Code snippet 6-35.txt

In this code sample, you enclose the BeginForm method in a using block. This method returns an instance of MvcForm that implements the IDisposable interface. At the end of the using block, the Dispose method is called, which renders the closing form tag. This provides a convenient approach for implementing HTML blocks in which the closing tag needs to be rendered at the end of a block of arbitrary HTML.

It's an unusual use of a using block, for sure, but being completely biased, we find it quite elegant. For those who find it completely distasteful, you can also use the following approach, which provides a bit of symmetry:

<% Html.BeginForm(); %>

  <label for="firstName">
  <input type="text" name="FirstName" id="firstname" />
  <input type="submit" value="Save" />

<% Html.EndForm(); %>
Code snippet 6-36.txt

Future helper methods that follow this pattern should be named according to the Begin* pattern.

The Html.Hidden method is used to render a hidden input. For example, the following code:

<%: Html.Hidden("wizardStep", "1") %>
Code snippet 6-37.txt

results in:

<input id="wizardstep" name="wizardStep" type="hidden" value="1" />
Code snippet 6-38.txt

The strongly typed version of this helper is Html.HiddenFor. Assuming our Model had a WizardStep property, you would use it as follows:

<%: Html.HiddenFor(m => m.WizardStep) %>
Code snippet 6-39.txt

Both the DropDownList and ListBox helpers render a <select /> HTML element. The difference is that ListBox is used for multiple item selection. It sets the multiple attribute to True in the rendered markup, allowing for multiple selections.

Typically, a select element serves two purposes:

For example, if you have a Product class with a CategoryID property, you may use a select element to display the value of the CategoryID property of Product, as well as to show all possible categories.

Thus, there's a bit of setup work to do in the Controller when using these helpers in order to provide these two bits of information. Here's an example of the code in the Controller that prepares an enumeration of SelectListItem instances. SelectListItem serves as the presentation Model for the DropDownList and ListBox methods:

[HttpGet]
public ActionResult Edit(int id) {
  NorthwindDataContext context = new NorthwindDataContext();
  var product = context.Products.Single(p => p.ProductID == id);

  ViewData["CategoryId"] = from c in p.Categories
    select new SelectListItem {
      Text = c.CategoryName,
      Value = c.CategoryID,
      Selected = (c.CategoryID == p.CategoryID)
    };

  return View(product);
}
Code snippet 6-40.txt

Now, in the View, you can render the dropdown list simply by referring to the IEnumerable<ListItem> that you put in the View data:

<%: Html.DropDownList("CategoryID") %>

There are other overloads that allow you to supply the enumeration directly. The SelectList class and the MultiSelectList class are helper classes used to transform an enumeration of any type into an IEnumerable<SelectListItem>. In the preceding example, a LINQ projection was used instead of these helper classes to transform an enumeration of Category instances into an enumeration of SelectListItem instances.

Although a bit more advanced than using the helper classes, using a LINQ projection lets you avoid using reflection to generate the enumeration.

Both Html.DropDownList and Html.ListBox have strongly typed counterparts, Html.DropDownListFor and Html.ListBoxFor, respectfully. The above DropDownList would be rendered using the strongly typed syntax shown below:

<%: Html.DropDownListFor(m => m.CategoryID) %>
Code snippet 6-41.txt

Html.Password is a simple helper used to render a password field. It's much like the TextBox helper, except that it does not retain the posted value, and it uses a password mask:

<%: Html.Password("UserPassword") %>
Code snippet 6-42.txt

and results in:

<input id="my-password" name="UserPassword" type="password" value="" />
Code snippet 6-43.txt

The strongly typed syntax for Html.Password, as you'd expect, is Html.PasswordFor. Here's how you'd use it to display the UserPassword property:

<%: Html.Password(m => m.UserPassword) %>
Code snippet 6-44.txt

Radio buttons are generally grouped together to provide a range of possible options for a single value. For example, if you wanted the user to select a color from a specific list of colors, you might use multiple radio buttons to present the choices. To group the radio buttons, you give each button the same name. Only the selected radio button is posted back to the server when the form is submitted.

The Html.RadioButton helper renders a simple radio button:

<%: Html.RadioButton("color", "red") %>
<%: Html.RadioButton("color", "blue", true) %>
<%: Html.RadioButton("color", "green") %>
Code snippet 6-45.txt

and results in:

<input id="color" name="color" type="radio" value="red" />
<input checked="checked" id="color" name="color" type="radio" value="blue" />
<input id="color" name="color" type="radio" value="green" />
Code snippet 6-46.txt

Html.RadioButton has a strongly typed counterpart, Html.RadioButtonFor. Rather than a name and a value, the strongly typed version takes an expression that identifies the object that contains the properties to render, followed by a value to submit if this radio button item is selected.

Partial is used to render a partial View, as opposed to a full View. Typically, this is used to render out a snippet of markup that is meant to be a reusable piece of the View. In the default View engine, a partial View is implemented as a UserControl (aka an .ascx file, although it is possible to use a full .aspx page as a partial View), but other View engines may use other means for implementing a partial View.

There are four overloads for Partial:

public void Partial(string partialViewName);
public void Partial(string partialViewName, object model);
public void Partial(string partialViewName, ViewDataDictionary viewData);
public void Partial(string partialViewName, object model,
  ViewDataDictionary viewData);
Code snippet 6-47.txt

A partial View may be rendered using a different View engine from your main View. This is useful in cases in which you might be reusing some View component code, which assumes a different View engine from the one you're using. The lookup for the partial View follows the same logic as the normal View lookup.

Here's an example of calling a partial View:

<%: Html. Partial("MyUserControl"); %>
Code snippet 6-48.txt

There's another very similar override, RenderPartial, which differs from Render in that it writes directly to the Response output stream; it does not return a string. Hence, you use <% rather than <%:, and you need the semicolon at the end for C#. To illustrate, the following two lines of code will result in the same input being written to the screen:

<% Html.RenderPartial("MyUserControl"); %>
<%: Html. Partial("MyUserControl"); %>
Code snippet 6-49.txt

So, how do you decide which to use?

Html.Partial is more convenient, since you can use the same <%: %> HTML Encoding Code Block syntax you're using with your other HTML Helpers. Html.RenderPartial will result in higher performance since it writes directly to the Response output stream, although it would require a lot of use (either high site traffic or repeated calls in a loop) before the difference would be measurable.

ASP.NET MVC 2 introduces a new pair of helpers which are which are similar to Partial and RenderPartial: Action and RenderAction. Whereas Partial renders the parent view's Model data using View markup in a separate file, Action actually executes a separate Controller action and displays the results. Action provides a lot more flexibility and re-use, because the child view can include different Model data, make use of separate Controller context, etc.

As with Partial and RenderPartial, the only difference between Action and RenderAction is that RenderAction will render the result directly to the Response (which is more efficient if the action returns a large amount of HTML) whereas Action returns a string with the result. For the sake of brevity, I'll use the term RenderAction to refer to both of these methods. Here's a quick look at how you might use this method. Suppose you have the following controller.

public class MyController {
  public ActionResult Index() {
    return View();
  }

  [ChildActionOnly]
  public ActionResult Menu() {
    var menu = GetMenuFromSomewhere();
      return PartialView(menu);
  }
}
Code snippet 6-50.txt

The Menu action grabs the Menu model and returns a partial view with just the menu.

<%@ Control Inherits="System.Web.Mvc.ViewUserControl<Menu>" %>
<ul>
<% foreach(var item in Model.MenuItem) { %>
  <li><%= item %></li>
<% } %>
</ul>
Code snippet 6-51.txt

In your Index.aspx view, you can now call into the Menu action to display the menu:

<%@ Page %>
<html>
<head><title></title></head>
<body>
  <%= Html.Action("Menu") %>
  <h1>Welcome to the Index View</h1>
</body>
</html>
Code snippet 6-52.txt

Notice that the Menu action is marked with a ChildActionOnlyAttribute. This attribute indicates that this action should not be callable directly via the URL. It's not required for an action to be callable via RenderAction.

We also added a new property to ControllerContext named IsChildAction. This lets you know whether the action method is being called via a RenderAction call or via the URL. This is used by some of our action filters which should do not get called when applied to an action being called via RenderAction such as AuthorizeAttribute and OutputCacheAttribute.

public class MenuOptions {
    public int Width { get; set; }
    public int Height { get; set; }
}
Code snippet 6-53.txt

[ChildActionOnly]
public ActionResult Menu(MenuOptions options) {
    return PartialView(options);
}
Code snippet 6-54.txt

<%= Html.Action("Menu",
  new { options = new MenuOptions { Width=400, Height=500} })%>
Code snippet 6-55.txt

[ChildActionOnly]
[ActionName("CoolMenu")]
public ActionResult Menu(MenuOptions options) {
    return PartialView(options);
}
Code snippet 6-56.txt

The aptly named TextArea helper renders a <textarea> tag, which is commonly used for entering multi-line data in a form. It properly encodes the value of the text area and attributes. For example:

<%: Html.TextArea("text", "hello <br/> world") %>
Code snippet 6-57.txt

results in:

<textarea cols="20" id="text" name="text" rows="2">hello <br /> world
</textarea>
Code snippet 6-58.txt

There are overloads that allow you to explicitly specify the columns and rows; for example:

<%: Html.TextArea("text", "hello <br /> world", 10, 80, null) %>
Code snippet 6-59.txt

results in:

<textarea cols="80" id="text" name="text" rows="10">hello <br /> world
</textarea>
Code snippet 6-60.txt

The strongly typed equivalent of Html.TextArea is Html.TextAreaFor. To render a text area for a Model's Description property, you'd use the following code:

<%: Html.TextAreaFor(m => m.Description) %>
Code snippet 6-61.txt

When there is an error for a particular field in the ModelState dictionary, you can use the ValidationMessage helper to display that message.

For example, in the following Controller action, we purposefully add an error to the Model state:

public ActionResult Index()
{
    var modelState = new ModelState();
    modelState.Errors.Add("Ouch");
    ModelState["Name"] = modelState;

    return View();
}
Code snippet 6-62.txt

Now in the View, you can display the error message for the "Name" field like so:

<%: Html.ValidationMessage("Name") %>
Code snippet 6-63.txt

which results in:

<span class="field-validation-error">Ooh!</span>
Code snippet 6-64.txt

This message is only shown if there is an error in the Model state for the key "Name". You can also call an override that allows you to override the error message from within the View:

<%: Html.ValidationMessage("Name", "Something is wrong with your name") %>
Code snippet 6-65.txt

which results in:

<span class="field-validation-error">Something wrong with your name  </span>
Code snippet 6-66.txt

Html.ValidationMessageFor is the strongly typed doppelganger of Html.ValidationMessage. The previous call could be rewritten as follows:

<%: Html.ValidationMessageFor(m => m.Name, "Something is wrong with your name") %>
Code snippet 6-67.txt

Html.ValidationSummary displays an unordered list of all validation errors in the ModelState dictionary. This summary can be styled using CSS. As an example, update the Controller action you used in the previous section to include another Model state error:

public ActionResult Index()
{
    var modelState = new ModelState();
    modelState.Errors.Add("Ouch");
    ModelState["Name"] = modelState;

    var modelState2 = new ModelState();
    modelState2.Errors.Add("Ooh!");
    ModelState["Age"] = modelState;

    return View();
}
Code snippet 6-68.txt

A call to:

<%: Html.ValidationSummary() %>
Code snippet 6-69.txt

results in:

<ul class="validation-summary-errors">
  <li>Ouch</li>
  <li>Ooh!</li>
</ul>
Code snippet 6-70.txt

This method also allows the specifying of a generic header message, which is displayed only if there is an error. For example:

<%: Html.ValidationSummary("An error occurred") %>
Code snippet 6-71.txt

results in:

<div class="validation-summary-errors">
  <span>An error occurred</span>
  <ul>
    <li>Ouch</li>
    <li>Ooh!</li>
  </ul>
</div>
Code snippet 6-72.txt

Spark (http://sparkviewengine.com/) is the brainchild of Louis DeJardin and is being actively developed with support for both MonoRail and ASP.NET MVC. It is of note because it blurs the line between markup and code. Hamilton, the founder of the Castle Project, toyed with similar ideas when trying to create an IronPython View engine (http://hammett.castleproject.org/?p=94), and Spark seems to have come up with a similar idea but takes it to the next level with several choices for making your Views aesthetically pleasing and functional.

First, you can use standard <% %> syntax:

<%
int total = 0;
foreach(var item in items)
{
  total += item.Quantity;
}
%>
Code snippet 6-76.txt

or a hash syntax for code blocks:

#int total = 0;
#foreach(var item in items)
#{
#   total += item.Quantity;
#}
Code snippet 6-77.txt

It's nice to have a choice, but neither of these two examples is revolutionary. The real spark of Spark is code like this:

<viewdata model="IEnumerable[[Person]]"/>
<ul class="people">
<li each="var person in ViewData.Model">
${person.LastName}, ${person.FirstName}
</li>
</ul>
Code snippet 6-78.txt

ScottHa's eyes blurred when Rob saw this, but then he realized what was happening. The each attribute is specific to Spark and provides a means of data binding to the supplied code expression. Thus, the <li> element will be repeated once per person. Within the <li> tag, you can use the Spark templating syntax to output properties of the current person instance.

This makes for a very natural HTML-centric syntax such that the code almost disappears in the markup. Remember that a View is only supposed to contain control flow that is specific to its one concern — generating the View. The View isn't a place for business logic or complex code, and Spark enables an idiomatic coding style that cleans up many of the kinds of inline code that makes some Views look messy. Additionally, Spark is well-formed XML, which opens the door for the use of editors and other accelerators in the future.

Spark has continued to grow in popularity since it was first released in July, 2008, to the point that it has become generally regarded as the most popular alternative View engine for ASP.NET MVC. In addition to the innovative syntax, it includes a lot of other exciting features, for example:

Spark is an exciting View engine to keep an eye on, and it is representative of the kind of exciting outside-the-box thinking that's happening around the "V" in MVC.

Another popular View engine is NHaml, created by Andrew Peters and released on his blog in December 2007. The project is a port of the popular Rails Haml View engine and is described on their blog as follows:

The goal of NHaml is to reduce the verbosity of XHTML, doing away with the excess of angle brackets required for most HTML pages. Some have called it "markup haiku."

The core syntax of NHaml is not unfamiliar and uses many of the same concepts that you'd see on a Web Forms ViewPage. The one main difference, however, is that white space (lines, spaces, tabs) counts in how things are marked up.

In the example shown in Listing 6-1, taken from the Andrew's blog, you can contrast a View written with Web Forms-style markup with one ported to the NHaml View Engine:

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
         AutoEventWireup="true"
         CodeBehind="List.aspx"
         Inherits="MvcApplication5.Views.Products.List" Title="Products" %>
<asp:Content ContentPlaceHolderID="MainContentPlaceHolder" runat="server">
  <h2><%: ViewData.CategoryName %></h2>
  <ul>

<% foreach (var product in ViewData.Products) { %>
      <li>
        <%: product.ProductName %>
        <div class="editlink">
          (<%: Html.ActionLink("Edit",
                new { Action="Edit", ID=product.ProductID })%>)
        </div>
      </li>
    <% } %>
  </ul>
  <%: Html.ActionLink("Add New Product", new { Action="New" }) %>
</asp:Content>

%h2= ViewData.CategoryName
%ul
  - foreach (var product in ViewData.Products)
    %li
      = product.ProductName
      .editlink
        = Html.ActionLink("Edit", new { Action="Edit", ID=product.ProductID })
= Html.ActionLink("Add New Product", new { Action="New" })

You can see from this example that NHaml does away with angle brackets quite nicely, and also uses white space to help in the formatting of the output.

NHaml also allows you to implement some core features of Ruby on Rails, namely, the use of Partials (akin to UserControls) and Layouts (akin to MasterPages).

The use of Partials in NHaml highlights the project's commitment to simplicity and less typing. To use a Partial in NHaml, you first need to create a bit of NHaml markup and save it in an .haml file. Their convention is to use an underscore as a prefix: "_Product.haml" to denote that the file is a Partial. To use this Partial, you just reference the name of the Partial without the extension, and it will be rendered inline (the Partial must be in the same physical directory as the file referencing it):

- foreach (var product in ViewData.Products)
  %li
    _ Product
Code snippet 6-79.txt

Layouts work in much the same way as Master Pages do with ASP.NET Web Forms, but with a few less features. With NHaml, the use of Layouts relies heavily on convention, in that a particular layout must be located in the Views/Shared folder and must use the same name as the Controller (you can override this behavior by passing in the MasterName argument to the View method from the Controller).

To create a Layout in NHaml, you create some NHaml markup and save it in the Views/Shared/[ControllerName] folder. The ProductController is used for the following example:

!!!
%html{xmlns="http://www.w3.org/1999/xhtml"}
  %head
    %title Rob's NHamlized MVC Application

%link{href="../../Content/Sites", rel="stylesheet", type="text/css"}
  %body
    #inner
      #header
        %h1 Welcome To My Store
      #maincontent
        _
      #footer
Code snippet 6-80.txt

This is a pretty simple page, and the part that matters, once again, is the underscore. All of the Views for the ProductController (unless the Action tells it to use a different layout) will be injected into this Layout where the underscore is.

You can also use application-wide Layouts with NHaml by creating an Application.haml file in the Views/Shared directory.

NVelocity is an Open Source templating engine and a port of the Apache/Jakarta Velocity project, built for Java-based applications. The NVelocity project did quite well for a few years, until 2004, when check-ins stopped and the project slowed down.

The Castle Project (the guys responsible for MonoRail, an alternative to ASP.NET Web Forms) forked the NVelocity project at that time and added some much needed bug fixes and changes to an alternative templating engine. NVelocity remains an interpreted language, but it performs quite well regardless.

MonoRail's fork of NVelocity includes a number of really clever improvements to the original. The most striking is their "Fancy foreach loop" inspired by Joel Spolsky's CityDesk language. This loop is almost reason enough to take a good, hard look at using NVelocity. Here's a sample from the NVelocity documentation:

#foreach($person in $people)
#beforeall
       <table>
               <tr><th>Name</th><th>Age</th></tr>
#before
       <tr
#odd
          Style='color:gray'>
#even
          Style='color:white'>

#each
       <td>$person.Name</td><td>$person.Age</td>

#after
       </tr>

#between
       <tr><td colspan='2'>$person.bio</td></tr>

#afterall
       </table>

#nodata
       Sorry No Person Found
#end
Code snippet 6-81.txt

The addition of all the directives such as #before, #between, and many others allow you to make quick work of even the most complex table markup.

Brail is an interesting View engine because it uses the Boo Language for its syntax. Boo is an object-oriented statically typed language for the CLR, but it has a Python language style to it, has significant white space, and includes some interesting ideas. It's not IronPython, to be clear; it's a whole new language. It promotes a syntax that tries to avoid explicit type-casting and includes syntactic sugar for patterns like string formatting and regular expressions intended to be wrist-friendly to the developer.

Brail was originally created as a View engine for the MonoRail project that has been ported over to ASP.NET MVC's interface. Brail support for ASP.NET MVC currently lives in the MVCContrib project at www.mvccontrib.org. Brail's Views are compiled, which makes them potentially faster than interpreted Views like those in NVelocity.

Where ASP.NET Web Forms has Master Pages, Brail has Layouts. A primary layout in Brail might look like this:

<html>
 <head>
        <title>My site</title>
 </head>
 <body>
        <h1>My sample site</h1>
        <div>
               ${childOutput}
        </div>
 </body>
</html>
Code snippet 6-82.txt

Note that the ${childOutput} indicates where the rendered View's output should appear within the larger layout. A "Hello World" might look like this:

<% output "Hello, powerful person! The time is ${DateTime.Now}"
if user.IsAdministrator %>
Code snippet 6-71.txt

Of course, you can do for loops, call methods, and all the things you'd expect. However, note the Boo-ism where there's an if control statement at the end of the line. Boo's fluent, easy-to-read syntax was one of the aspects that got the MonoRail team excited about Brail, and now it's an option for ASP.NET MVC.