网博士cases_list_to_html.asp,ASP.NET MVC 3 Custom HTML Helpers- Best Practices/

I use HtmlHelpers all the time, most commonly to encapsulate the generation of boilerplate HTML, in case I change my mind. I've had such helpers as:

Html.BodyId(): generates a conventional body id tag for referencing when adding custom css for a view.

Html.SubmitButton(string): generates either an input[type=submit] or button[type=submit] element, depending on how I want to style the buttons.

Html.Pager(IPagedList): For generating paging controls from a paged list model.

etc....

One of my favorite uses for HtmlHelpers is to DRY up common form markup. Usually, I have a container div for a form line, one div for the label, and one label for the input, validation messages, hint text, etc. Ultimately, this could end up being a lot of boilerplate html tags. An example of how I have handled this follows:

public static MvcHtmlString FormLineDropDownListFor(this HtmlHelper helper, Expression> expression, IEnumerable selectList, string labelText = null, string customHelpText = null, object htmlAttributes = null)

{

return FormLine(

helper.LabelFor(expression, labelText).ToString() +

helper.HelpTextFor(expression, customHelpText),

helper.DropDownListFor(expression, selectList, htmlAttributes).ToString() +

helper.ValidationMessageFor(expression));

}

public static MvcHtmlString FormLineEditorFor(this HtmlHelper helper, Expression> expression, string templateName = null, string labelText = null, string customHelpText = null, object htmlAttributes = null)

{

return FormLine(

helper.LabelFor(expression, labelText).ToString() +

helper.HelpTextFor(expression, customHelpText),

helper.EditorFor(expression, templateName, htmlAttributes).ToString() +

helper.ValidationMessageFor(expression));

}

private static MvcHtmlString FormLine(string labelContent, string fieldContent, object htmlAttributes = null)

{

var editorLabel = new TagBuilder("div");

editorLabel.AddCssClass("editor-label");

editorLabel.InnerHtml += labelContent;

var editorField = new TagBuilder("div");

editorField.AddCssClass("editor-field");

editorField.InnerHtml += fieldContent;

var container = new TagBuilder("div");

if (htmlAttributes != null)

container.MergeAttributes(new RouteValueDictionary(htmlAttributes));

container.AddCssClass("form-line");

container.InnerHtml += editorLabel;

container.InnerHtml += editorField;

return MvcHtmlString.Create(container.ToString());

}

public static MvcHtmlString HelpTextFor(this HtmlHelper helper, Expression> expression, string customText = null)

{

// Can do all sorts of things here -- eg: reflect over attributes and add hints, etc...

}

Once you've done this, though, you can output form lines like this:

model.Property1) %>

model.Property2) %>

model.Property3) %>

... and BAM, all your labels, inputs, hints, and validation messages are on your page. Again, you can use attributes on your models and reflect over them to get really smart and DRY. And of course this would be a waste of time if you can't standardize on your form design. However, for simple cases, where css can supply all the customization you need, it works grrrrrrrrreat!

Moral of the story -- HtmlHelpers can insulate you from global design changes wrecking hand crafted markup in view after view. I like them. But you can go overboard, and sometimes partial views are better than coded helpers. A general rule of thumb I use for deciding between helper vs. partial view: If the chunk of HTML requires a lot of conditional logic or coding trickery, I use a helper (put code where code should be); if not, if I am just outputting common markup without much logic, I use a partial view (put markup where markup should be).

Hope this gives you some ideas!