Like web forms, MVC allows you to customize the building blocks for developing in MVC. Extension helpers are so easy to write because all it takes is an extension method like the following:

public static class MyExtensions
{
    public static string CustomHiddenField(this HtmlHelper html, int key)
    {
         return string.Format(“<input type=’hidden’ value='{0}’ />”, key);
    }
}

And now we have our extension that can be used within an MVC app (as long as the namespace is declared in an Imports statement, or in the configuration file):

<%= Html.CustomHiddenFIeld(5) %>

And voila, this requires less work and allows us to change one implementation to change all of the references (in case we wanted to switch it to another mechanism for storage, say a javascript block with a JSON object to store the key, for example).

That was a brief example to get the picture, and a picture of what you see with most custom helpers.  But, I am tending to dislike the approach this implementation takes; while this example is simple, other html helpers in the .NET MVC framework tend to look like the BeginForm statement in the following:

BeginForm(this HtmlHelper htmlHelper, string actionName, string controllerName, RouteValueDictionary routeValues, FormMethod method, IDictionary<string, object> htmlAttributes);

You get the picture; with multiple overloads, you may end up inserting values in the wrong object (as some overload take an object for the routeValues and html attributes collection).  It may be easier to use an alternative approach, as the exact method overload that would be very convenient to have is missing.  Hence, a better design can be to take advantage of the fluent interface approach to designing a UI.  As an alternative to the form design above, I created a component that worked like the following:

public class HtmlFormBuilder
{
 private HtmlForm _form = new HtmlForm();

 public HtmlFormBuilder Action(string actionName, RouteValueDictionary routeValues)
 {
  return Action(actionName, null, routeValues);
 }

 public HtmlFormBuilder Action(string actionName, string controllerName, RouteValueDictionary routeValues)
 {
  _form.ActionName = actionName;
  _form.ControllerName = controllerName;
  _form.RouteValues = routeValues;
  return this;
 }

 public HtmlFormBuilder HtmlAttributes(object attributes)
 {
  TagAttributeReader reader = new TagAttributeReader();
  reader.ReadAttributes(attributes);

  _form.HtmlAttributes = reader.Attributes;
  return this;
 }

 public HtmlFormBuilder HtmlAttributes(IDictionary<string, object> attributes)
 {
  _form.HtmlAttributes = attributes;
  return this;
 }

 public HtmlFormBuilder Method(FormMethod method)
 {
  if (_form.HtmlAttributes == null)
   _form.HtmlAttributes = new Dictionary<string, object>();

  _form.HtmlAttributes[“method”] = method.ToString();
  return this;
 }

 public override string Render()
 {
  .. 
 }
}

A form builder uses a custom object that represents the HtmlForm in the underlying implementation.  The builder assigns values within the form, and creates the fluent interface by returning an instance of the builder in each method except for Render.  So the action method assigns action values to the underlying object, simply by passing the params on to the object.  Adding overloads makes it more convenient to the user. 

The Render method is the final part of the process, which returns a string to get output to the browser.  The rendering process can use a TagBuilder or StringBuilder to create the form statement and return it to the caller.  Note this only generates the beginning form tag.  Also, I omitted the render as the implementation I chose is not a standard implementation because it’s a part of my Nucleo framework not implemented yet.

This way, we have a more fluent design; if you don’t want to assign a value to something, you don’t have to pass null, but can omit the method (even though it assigns null in the underlying presentation because null is the absence of a value), and strings together a response like:

<%= Html.BeginForm().Method(FormMethod.Get).Action(“MyAction”, null).HtmlAttributes(new { id = “formid” }).Render() %>

In this scenario, it may be more verbose, but it’s more readable in my opinion.  It’s the approach a lot of MVC control builders are using (MvcContrib and Telerik are two that come to mind).