I demonstrated the use of FluentHtml (with behaviours), the Grid and Pager components, the ActionResult assertions and the route testing extensions.

Slides and code can be downloaded here.

I’ve also put together a guide to contributing to MvcContrib using git for those without git experience.

• Part 1 – Introduction
• Part 2 – New Syntax
• Part 3 – GridModels and GridRenderes
• Part 4 – Limitations of the WebFormsViewEngine
• Part 5 – The Action Syntax

The rewritten MvcContrib grid now has an alternative syntax thanks to the work of Will Shaver. This syntax is called the ‘Action’ syntax as it makes heavy use of the System.Action delegate.

Enabling the ActionSyntax

By default, the methods associated with the Action Syntax will not show up as they are extension methods that live in a different namespace to the rest of the grid. Out of the box only the default syntax will work. To enable the Action Syntax you’ll need to either import the MvcContrib.UI.Grid.ActionSyntax namespace either in your .aspx view…

<%@ Import Namespace="MvcContrib.UI.Grid.ActionSyntax" %>

…or in your web.config’s namespace import section:

<system.web>
  <pages>
    <namespaces>
        <add namespace="MvcContrib.UI.Grid.ActionSyntax" />
    </namespaces>
  </pages>
</system.web>

Comparing the two syntaxes

There are several differences between the two syntaxes. Here is a grid definition using the default syntax:

<%= Html.Grid(Model)
	.Columns(column => {
  		column.For(x => x.Id).Named("Person ID");
     		column.For(x => x.Name);
     		column.For(x => x.Gender);    
     		column.For(x => x.DateOfBirth).Format("{0:d}");
		column.For("View Person").Named("").Partial("ViewPersonPartial"); //Example of using a Partial view for complex cells
     	}).RowStart(row => string.Format("<tr{0}>", row.IsAlternate ? "style=\"background-color:#CCDDCC\"" : "")) 
  %>

Here we’re specifying that the View Person column is a custom column that should be rendered using a Partial View, and the start of every alternate row has a background colour**.

Here is the same grid defined using the ActionSyntax:

<% Html.Grid(Model).Columns(column => {
     		column.For(x => x.Id).Named("Person ID");
     		column.For(x => x.Name);
     		column.For(x => x.Gender);
     		column.For(x => x.DateOfBirth);
                column.For("View Person").Named("").Action(p =>	{ %>
                     <td style="font-weight:bold">
	                <%= Html.ActionLink("View Person", "Show", new { id = p.Id })%>
	             </td>
                <% });
     	}).RowStart((p,row)  => {     
             if (row.IsAlternate) { %>
                   <tr style="background-color:#CCDDCC">
             <%  }  else  { %>
                 <tr>
             <% }
    }).Render(); %>

Note the following differences:

• The ActionSyntax requires the use of <% %> tags rather than <%= %> tags.
• The ActionSyntax requires that you end your grid definition with a call to the Render method or the grid will not show up if you do not call Render.
• You must terminate the call to Render with a semicolon
• You can directly embed HTML in the grid definition rather than using strings or partial views

Both syntaxes have their advantages and disadvantages but the end result is the same. You’re free to use whichever one you prefer.

**Both the partial view/actionsyntax approach are designed only for complex column definitions. This example was quite contrived and you could achieve the same result with a far simpler approach:

<style type="text/css">
.gridrow_alternate { background-color:#CCDDCC; }
</style>
<%= Html.Grid(Model)
	.Columns(column => {
  		column.For(x => x.Id).Named("Person ID");
     		column.For(x => x.Name);
     		column.For(x => x.Gender);    
     		column.For(x => x.DateOfBirth).Format("{0:d}");
		column.For(x => Html.ActionLink("View Person", "Show", new { id = p.Id }))
                           .Attributes(x => new Hash(style => "font-weight:bold"));
     	}) %>

• Part 1 – Introduction
• Part 2 – New Syntax
• Part 3 – GridModels and GridRenderes
• Part 4 – Limitations of the WebFormsViewEngine
• Part 5 – The Action Syntax

I was recently asked a question by one of the other MvcContrib comitters, Will Shaver, about why the ToString method of the Grid does not return the HTML for the grid, but instead writes the html its internal textwriter and then returns null.

This is the offending piece of code:

public override string ToString() 
{
	_gridModel.Renderer.Render(_gridModel, DataSource, _writer, context);
	return null;
}

This means that when ToString is called on the grid the GridRenderer will render the appropriate HTML to a textwriter (which is actually the HTTP Response output stream). From the end user’s perspective, this shouldn’t make a difference because it ‘appears’ that the grid is being rendered at the correct location:

<%= Html.Grid(Model.People).Columns(...) %>

ToString is implicitly called at the end of the <%= %> block which causes the rendering to occur.

What a silly way to create some html!

Yes, it may seem like a strange way of doing things but there is actually a good reason for this. In order to support rendering Partials for parts of the grid it is necessary that the grid is written directly to the response stream due to limitations of the WebForms View Engine.

What about passing a custom TextWriter to IView.Render?

The ASP.NET MVC IView represents the view that will be rendered. Take a look at the signature for its Render method:

void Render(ViewContext viewContext, TextWriter writer);

You might think that it would be possible to pass a StringWriter to the Render method, capture the output of the partial view and then store it internally in the grid. Unfortunately, this isn’t possible. I’m guessing the TextWriter parameter here is a hook for a future extensibility point – the current implementation of WebFormView completely ignores the parameter. In fact, internally WebFormView has to make use of HttpContext.Current in order to work around the limitation of .aspx/web forms.

What about the BlockRenderer?

MvcContrib contains a class called the BlockRenderer that can be used to capture the outputs of a view by making use of a Response Filter. While I could have used this approach, it suffers from several major flaws. In order for this approach to work, it is necessary to Flush the response stream before inserting the CapturingResponseFilter. This causes problems if you’re trying to do anything funky with HTTP Headers, or even something as simple as trying to set the Content Type. Check out this post on the MVC Forums for more details. There are other hacks that can be used, but none of them are ideal

In the end I decided the least evil approach was to render to Response.Output from within ToString as it causes the fewest problems for the end user. Hopefully with the release of ASP.NET 4.0 the MVC Team will be allowed to make some changes to the underlying WebForms engine in order to make it possible to capture view output.

• Part 1 – Introduction
• Part 2 – New Syntax
• Part 3 – GridModels and GridRenderes
• Part 4 – Limitations of the WebFormsViewEngine
• Part 5 – The Action Syntax

Internally, the new MvcContrib grid makes use of the GridModel and GridRenderer classes to create the grid definition and then render it. It is possible to make use of these classes yourself to customise the grid.

Grid Models

The GridModel stores the definition for the grid. That is, it contains column definitions, custom attributes and the renderer to use (see below). Each time you call a method on the Grid class it is delegated to the underlying GridModel. For example, calling the Columns defines a collection of GridColumn objects which are instantiated and stored in the GridModel:

<%= Html.Grid(Model.People).Columns(column => {
               column => column.For(x => x.Name);
               column => column.For(x => x.DateOfBirth);
}) %>

Instead of defining columns in your view, you can create your own GridModel and then pass this object to a call to Html.Grid:

public class PersonGridModel : GridModel<Person> {
    public PersonGridModel() {
        Column.For(x => x.Name);
        Column.For(x => x.DateOfBirth);
    }
}

<%= Html.Grid(Model.People).WithModel(new PersonGridModel()) %>

Note that GridModels aren’t limited just to column definitions. Everything that you could invoke by calling Html.Grid has an equivalent method on the GridModel (eg setting Empty Text, custom section overrides, header attributes etc).

There are several advantages of this approach:

• If you have large grid definitions using a GridModel can help to keep the view uncluttered.
• It is easy to re-use the same grid in multiple locations.
• You can re-use common grid code through inheritance.

There is one other benefit to using a GridModel. Visual Basic 2008 doesn’t support Lambda Statements meaning that it is not possible to use the Columns() method on the Grid directly. By using a grid model then you can still make use of the grid from within VB (if you’re that way inclined).

Grid Renderers

Internally, it is the job of the GridRenderer to take a GridModel and render it to the output stream. The default GridRenderer is the HtmlTableGridRenderer. Which, surprisingly enough, renders the grid as an HTML table. By specifying your own GridRenderer, you can completely alter how the grid is rendered without resorting to completely rewriting the grid component.

For example, in one of my larger ASP.NET MVC applications I frequently have the need to output data as an Excel spreadsheet and I used the grid to do so. In order to make this work I had to inherit from GridBase and override the methods related to generating output and then define a new set of helper methods to cater for the various Grid overloads. In the end I ended up with several overloads like this:

public static void ExcelGrid<T>(this HtmlHelper helper, string viewDataKey, Action<IRootGridColumnBuilder<T>> columns) where T : class
public static void ExcelGrid<T>(this HtmlHelper helper, string viewDataKey, Action<IRootGridColumnBuilder<T>> columns, Action<IGridSections<T>> sections) where T : class
public static void ExcelGrid<T>(this HtmlHelper helper, string viewDataKey, IDictionary htmlAttributes, Action<IRootGridColumnBuilder<T>> columns) where T : class 
public static void ExcelGrid<T>(this HtmlHelper helper, string viewDataKey, IDictionary htmlAttributes, Action<IRootGridColumnBuilder<T>> columns, Action<IGridSections<T>> sections) where T : class
public static void ExcelGrid<T>(this HtmlHelper helper, IEnumerable<T> dataSource, Action<IRootGridColumnBuilder<T>> columns) where T : class
public static void ExcelGrid<T>(this HtmlHelper helper, IEnumerable<T> dataSource, Action<IRootGridColumnBuilder<T>> columns, Action<IGridSections<T>> sections) where T : class 
public static void ExcelGrid<T>(this HtmlHelper helper, IEnumerable<T> dataSource, IDictionary htmlAttributes, Action<IRootGridColumnBuilder<T>> columns) where T : class 
public static void ExcelGrid<T>(this HtmlHelper helper, IEnumerable<T> dataSource, IDictionary htmlAttributes, Action<IRootGridColumnBuilder<T>> columns, Action<IGridSections<T>> sections) where T : class

…which was largely a duplication of the Grid overloads in mvccontrib. They could then be used like this:

<% Html.ExcelGrid(Model.People, column => {
         column.For(x => x.Name);
         column.For(x => x.DateOfBirth);
 }); %>

…which would produce the grid as Excel-XML.

With the new grid I can create a new GridRenderer implementation and then use it like this, with no need to create additional HtmlHelper extensions:

<%= Html.Grid(Model.People).Column(column => {
               column => column.For(x => x.Name);
               column => column.For(x => x.DateOfBirth);
}).RenderUsing(new ExcelGridRenderer<Person>());

The ExcelGridRenderer could inherit from GridRenderer and override the methods needed for constructing the grid header, footer, rows etc. You may notice that the methods on GridRenderer are very similar to those on the GridBase class. This is not a coincidence – most of the code in the GridRenderer is re-used from the old GridBase.

Note it is also possible to specify the renderer from within a GridModel:

public class PersonGridModel : GridModel<Person> {
    public PersonGridModel() {
        Column.For(x => x.Name);
        Column.For(x => x.DateOfBirth);
        RenderUsing(new ExcelGridRenderer<Person>());
    }
}

Hopefully this brief introduction to GridRenderers and GridModels shows how it is possible to make your grids extendable and reusable. In my next post I’m going to focus on Paging in more detail. My next post covers working around some of the issues of the WebForms View Engine.

• Part 1 – Introduction
• Part 2 – New Syntax
• Part 3 – GridModels and GridRenderes
• Part 4 – Limitations of the WebFormsViewEngine
• Part 5 – The Action Syntax

Edit: 28 Feb 09 I have removed the use of Partial views in the latest MvcContrib trunk for certain areas where it didn’t really make sense. The examples below have been updated to reflect this.

The updated version of the MvcContrib grid has a new syntax that uses method chaining and lambda expressions to build a fluent interface. Here is a grid defined with the new syntax:

<%= Html.Grid(Model.People).Columns(column => {
     		column.For(x => x.Id).Named("Person ID");
     		column.For(x => x.Name);
     		column.For(x => x.DateOfBirth).Format("{0:d}");
     	})
        .Attributes(style => "width:100%")
     	.Empty("There are no people.")
     	.RowStart(row => "<tr foo='bar'>") %>

Compare this to the same grid defined using the old syntax:

<%
  Html.Grid(Model.People,
    new Hash(empty => "There are no people", style => "width:100%"),
    column => {
	column.For(x => x.Id, "Person Id");
     	column.For(x => x.Name);
     	column.For(x => x.DateOfBirth).Format("{0:d}");
    }, sections => {
       sections.RowStart(item => { %>
          <tr> <!-- some custom html for the row start here -->
   <% });
%>

Note how grid options (eg Empty) are now specified as part of the fluent interface rather than part of the HTML Attributes dictionary (which I always felt was messy). The use of method chaining also means that it is no longer possible to embed html blocks inside the grid definition (eg RowStart). However, you can still achieve the same functionality using the RowStart method and specifying specifying a lambda that will return the HTML string to output.

The column definitions are almost identical identical.

Paging support

Unlike its predecessor, the new grid does not have any logic for dealing with paging. This has all been moved to a separate Pager component. The old grid rendered the pager in its footer, while with the new grid you’d need to write your page like this:

<%= Html.Grid(Model.People).Columns(column => {
     		column.For(x => x.Id).Named("Person ID");
     		column.For(x => x.Name);
     		column.For(x => x.DateOfBirth).Format("{0:d}");
}) %>
 
<%= Html.Pager(Model.People) %>

Where’s the code?

The code for the new grid is not in the mvccontrib release, so if you want to play with it you’ll need to download and build the source. Alternatively, I’ve put together a custom build that can be downloaded here for the subversion-impaired.

In my next post, I’ll be focussing on extending the grid by using GridModels and GridRenderers.

• Part 1 – Introduction
• Part 2 – New Syntax
• Part 3 – GridModels and GridRenderes
• Part 4 – Limitations of the WebFormsViewEngine
• Part 5 – The Action Syntax

Over the next couple of weeks I’m hoping to write a few posts on the upgrades I’m doing to the MvcContrib grid component. These are the features that I’m planning on adding:

A Fluent Interface

Like the HTML-helpers built into the ASP.NET MVC framework, the mvccontrib grid suffers from ‘overload hell’. Switching to a fluent interface should provide a cleaner and more discoverable API.

Discouraging logic in Views

One side effect of the fluent interface is that it will no longer be possible to use the grid’s section overrides. However, I consider this to be a good thing. Embedding custom sections makes it all to easy to get stuck in ‘tag soup’. To make up for this, the new grid will support rendering partials for custom sections.

Reusable Grid Models

The new grid will support reusable grid definitions. That is, you will be able to define a grid in a external class and then reference this from your views. One benefit of this approach is that it means the grid will finally be accessible to VB users. The current grid is C#-only due to its use of lambda-statements for defining columns.

Customisable Grid Rendering

The existing grid only supports rendering in an HTML table. This means that if you wanted to render a grid in a different format (for example, as an OpenXML Spreadsheet) it meant you needed to inherit from the Grid class, override several methods and then create a new helper. The new grid will allow a custom GridRenderer class to be provided in the grid definition. Rendering as an HTML table will still be the default behaviour.

Separate Pagination Component

The current grid has built in support for paging. With the new grid, this will be moved into a separate component.

Sorting

Time permitting, the new grid will have support for sorting.

In my next post I’ll focus on the grid’s Fluent Interface.

The ASP.NET MVC ModelState dictionary allows you to record validation errors which can then be displayed in your web page.

For example, imagine you add a textbox to a page using the MVC framework’s built-in HTML helpers, then this will render a standard text field:

Your name: <%= Html.TextBox("Name") %>

In your controller, if you add an error to the ModelState dictionary with the same name as the textbox, then the HTML helper will change the styling of the input field by adding a css class of “input-validation-error”.

public class HomeController : Controller {
   public ActionResult Index() {
       ModelState.AddModelError("Name", "Please enter a name");
       return View(new MyViewModel { Name = "" });
   }
}

Using the default ASP.NET MVC template, it will add a red border with a light pink background:

You can also display the actual validation errors by making use of the ValidationSummary helper:

<%= Html.ValidationSummary() %>
Enter your name: <%= Html.TextBox("Name") %>

Which will display something like this:

ModelState with FluentHtml

By default, the Fluent HTML helpers in MvcContrib do not have support for ModelState. However, it is very easy to add support for this by writing a custom MemberBehaviour (I previously wrote about extending the HTML helpers with MemberBehaviors here)

Here is the implementation of the ModelStateMemberBehavior class:

public class ModelStateMemberBehavior : IMemberBehavior {
	private readonly ModelStateDictionary modelState;
 
	public ModelStateMemberBehavior(ModelStateDictionary modelState) {
		this.modelState = modelState;
	}
 
	public void Execute(IMemberElement element) {
		ModelState state;
		if (element.Builder.Attributes.ContainsKey("name")) {
			if (modelState.TryGetValue(element.Builder.Attributes["name"], out state)) {
				element.Builder.AddCssClass("input-validation-error");
			}
		}
	}
}

This class will check whether the name of the element being rendered is present in the specified ModelState dictionary. If so, it will add a css class of “input-validation-error” to the element being rendered.

Now we need to hook this into the HTML helpers. This can be done by implementing the IViewModelContainer interface on your base View Page:

public class MyBaseViewPage<T> : ViewPage<T>, IViewModelContainer<T> where T : class {
   private List<IMemberBehavior> memberBehaviors = new List<IMemberBehavior>();
 
   protected override void SetViewData(ViewDataDictionary viewData) {
      base.SetViewData(viewData);
      behaviors.Add(new ModelStateMemberBehavior(ViewData.ModelState));
   }
 
   public T ViewModel {
      get { return ViewData.Model; }
   }
 
   public IEnumerable<IMemberBehavior> MemberBehaviors {
	get { return memberBehaviors; }
   }
}

Now, so long as all your view pages inherit from MyBaseViewPage, any calls to the fluent HTML helpers will have support for ModelState:

Your name: <%= this.TextBox(model => model.Name) %>

One of the great things about these helpers is that you can change how the HTML is rendered by writing custom IMemberBehavior objects. For example, the helpers come with a set of attributes that you can use to decorate your model:

public class Customer {
   [MaxLength(50)]
   public string Name { get; set; }
}

Then, when you render your view, the HTML helper will automatically detect the presence of this attribute and render a “maxlength” attribute accordingly. For example, this textbox helper…

<%= this.TextBox(m => m.Customer.Name) %>

…would render this html:

<input type="text" maxlength="50" id="Customer_Name" name="Customer.Name" />

I wanted to take this a step further and integrate it with my validation library, so the HTML helpers will automatically pick up maxlength/required attributes from my validator classes.

Step 1: Custom Validator Class

The first stage was to create a metadata class to hold information about a validator.

public class PropertyModel {
	public int MaxLength { get; set; }
	public bool Required { get; set; }
	public PropertyInfo Property { get; private set; }
 
	public PropertyModel(PropertyInfo property) {
		Property = property;
	}
}

Next, I introduced a new interface, IPropertyDescriptor, that all my validator classes will implement. This interface defines the signature for a method that creates PropertyModel instances based on a PropertyInfo:

public interface IPropertyDescriptor {
	PropertyModel GetPropertyModel(PropertyInfo property);
}

Next, I added a custom base-class for all my validators which implements the above interface:

public abstract class Validator<T> : AbstractValidator<T>, IPropertyDescriptor {
	public PropertyModel GetPropertyModel(PropertyInfo property) {
		var model = new PropertyModel(property);
 
		var validators = this.OfType<IPropertyValidatorContainer<T>>().Where(x => x.Property == property).Select(x => x.Validator);
		foreach (var validator in validators) {
			if (HandleLengthValidator(validator, model)) continue;
			if (HandleRequiredValidator(validator, model)) continue;
		}
 
		return model;
	}
 
	private bool HandleLengthValidator(IPropertyValidator<T> validator, PropertyModel model) {
		var length = validator as ILengthValidator;
		if(length != null) {
			model.MaxLength = length.Max;
			return true;
		}
		return false;
	}
	private bool HandleRequiredValidator(IPropertyValidator<T> validator, PropertyModel model) {
		var required = validator as INotNullValidator;
		if(required != null) {
			model.Required = true;
			return true;
		}
		return false;
	}	
}

Essentially, the GetPropertyModel method iterates through all of the property validators to see if any required or max-length validators have been defined. If so, it records them in the PropertyModel object.

I can now define my validators as usual, but they now inherit from my new Validator<T> class, rather than AbstractValidator<T>.

public class CustomerValidator : Validator<Customer> {
   public CustomerValidator() {
     RuleFor(customer => customer.Name).Length(0, 50);
   }
}

Step 2: Custom Validator Factory

The next stage is to impelement a custom validator factory that can be used to instantiate validators. For this example, I’ll be using the Windsor IoC container.

Firstly, in my application startup routine I need to register all of my validators with Windsor:

var container = new WindsorContainer();
container.Register(AllTypes.Of(typeof(IValidator<>)).FromAssembly(typeof(CustomerValidator).Assembly).WithService.Base());

Next, I create a validator factory that uses Windsor (or more accurently, Microkernel) to create the validator instances.

public class ValidatorFactory : IValidatorFactory {
	private readonly IKernel container;
 
	public ValidatorFactory(IKernel container) {
		this.container = container;
	}
 
	public IValidator<T> GetValidator<T>() {
		return container.TryResolve<IValidator<T>>();
	}
 
	public IValidator GetValidator(Type type) {
		var genericType = typeof(IValidator<>).MakeGenericType(type);
		return (IValidator)container.TryResolve(genericType);
	}
}

Note that TryResolve is an extension method on IKernel that will attept to resolve a component and return null if it fails (by default, Windsor/Microkernel will throw an exception).

This validator factory can now be registered with the container:

container.Register(Component.For<IValidatorFactory>().ImplementedBy<ValidatorFactory>());

Step 3: The PropertyModelFactory

The next stage is to create a class that can be used to locate the correct validator from a PropertyInfo object (by using the validator factory) and return a corresponding PropertyModel.

public class PropertyModelFactory : IPropertyDescriptor {
   private IValidatorFactory validatorFactory;
 
   public PropertyModelFactory(IValidatorFactory validatorFactory) {
     this.validatorFactory = validatorFactory;
   }
 
  public PropertyModel GetPropertyModel(PropertyInfo property) {
     var descriptor = validatorFactory.GetValidator(property.ReflectedType) as IPropertyDescriptor;
     if(descriptor != null) {
        return descriptor.GetPropertyModel(property);
     }
     return null;
  }
}

Again, this needs to be registered with the container:

container.Register(Component.For<IPropertyDescriptor>().ImplementedBy<PropertyModelFactory>());

Step 4: Custom IMemberBehavior

Next, we need to create a custom IMemberBehavior that will make use of the PropertyModelFactory:

public class ValidatorMemberBehaviour : IMemberBehavior {
   private readonly IPropertyDescriptor descriptor;
 
   public ValidatorMemberBehaviour(IPropertyDescriptor descriptor) {
      this.descriptor = descriptor;
   }
 
   public void Execute(IMemberElement element) {
      if (element.ForMember == null) return;
 
      var property = element.ForMember.Member as PropertyInfo;
      if(property == null) return;
 
      var model = descriptor.GetPropertyModel(property);
      if (model == null) return;
 
      var maxLengthMethod = element.GetType().GetMethod("MaxLength");
 
      if(maxLengthMethod != null) {
         element.Builder.MergeAttribute("maxlength", model.MaxLength.ToString());				
      }
      if(model.Required) {
         element.Builder.AddCssClass("required");
      }
   }
}

MemberBehaviors are invoked when certain HTML helper objects are created, so this behaviour now needs to be registered with our ViewPage:

public class MyViewPage<T> : ModelViewPage<T> where T : class {
   public MyViewPage() 
     : base(new ValidatorMemberBehaviour(ServiceLocator.Resolve<IPropertyDescriptor>())) { }
}

Note that the ServicLocator static class is just a wrapper around Windsor.

So now the HTML Helpers will use my validator definitions to generate required/maxlength attributes. I think the extensibility of these helpers is incredibly powerful and I am planning on using them going forward in my next project.