Question

I’m trying to display a view model using an editor template that wraps the model in a fieldset before applying a base Object editor template.

My view:

@model Mvc3VanillaApplication.Models.ContactModel

@using (Html.BeginForm())
{
    @Html.EditorForModel("Fieldset")
}

---

Uses a fieldset template (Views/Shared/EditorTemplates/Fieldset.cshtml):

<fieldset>
    <legend>@ViewData.ModelMetadata.DisplayName</legend>
    @Html.EditorForModel()
</fieldset>

---

Which in turn uses a basic template for all objects (Views/Shared/EditorTemplates/Object.cshtml):

@foreach (var prop in ViewData.ModelMetadata.Properties.Where(x => 
    x.ShowForEdit && !x.IsComplexType && !ViewData.TemplateInfo.Visited(x)))
{
    @Html.Label(prop.PropertyName, prop.DisplayName)
    @Html.Editor(prop.PropertyName)
}

---

That’s my intent anyway. The problem is that while the page renders with a fieldset and a legend, the Object template isn’t applied so no input controls are displayed.

If I change the view to not specify the “Fieldset” template then my model’s properties are rendered using the Object template, so it’s not that my Object template can’t be found.

Is it possible to pass the same model through multiple templates?

For what it’s worth, the view model looks like this:

namespace Mvc3VanillaApplication.Models
{
    [System.ComponentModel.DisplayName("Contact Info")]
    public class ContactModel
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
    }
}

Answer 1

I implemented what you have, and was able to reproduce it. I set a break point in Object.cshtml so I could inspect it and I was caught off guard to realize that it wasn’t even hitting the object template when the fieldset template was being used. Then I stepped through the fieldset template and saw it was calling the template just fine, so something must be happening in the code which prevents it from displaying the object template.

I opened up the MVC3 source code, searched for EditorForModel and found the correct function.

public static MvcHtmlString EditorForModel(this HtmlHelper html) {
    return MvcHtmlString.Create(TemplateHelpers.TemplateHelper(html, html.ViewData.ModelMetadata, String.Empty, null /* templateName */, DataBoundControlMode.Edit, null /* additionalViewData */));
}

Obviously this wasn’t it, so I pressed F12 on TemplateHelpers.TemplateHelper, and once there again I pressed F12 on single line call which brings you to the meat of the function. Here I found this short bit of code starting on line 214 of TemplateHelpers.cs:

// Normally this shouldn't happen, unless someone writes their own custom Object templates which
// don't check to make sure that the object hasn't already been displayed
object visitedObjectsKey = metadata.Model ?? metadata.RealModelType;
if (html.ViewDataContainer.ViewData.TemplateInfo.VisitedObjects.Contains(visitedObjectsKey)) {    // DDB #224750
    return String.Empty;
}

Those comments are actually in the code, and here we have the answer to your question: Can one model be passed through multiple editor templates?, the answer is no*.

That being said, this seems like a very reasonable use case for such a feature, so finding an alternative is probably worth the effort. I suspected a templated razor delegate would solve this wrapping functionality, so I tried it out.

@{
    Func<dynamic, object> fieldset = @<fieldset><legend>@ViewData.ModelMetadata.DisplayName</legend>@Html.EditorForModel()</fieldset>;
}

@using (Html.BeginForm())
{
    //@Html.EditorForModel("Fieldset")
    //@Html.EditorForModel()
    @fieldset(Model)
}

And viola! It worked! I’ll leave it up to you to implement this as an extension (and much more reusable) method. Here is a short blog post about templated razor delegates.

---

* Technically you could rewrite this function and compile your own version of MVC3, but it’s probably more trouble than it’s worth. We tried to do this on the careers project when we found out that the Html.ActionLink function is quite slow when you have a few hundred routes defined. There is a signing issue with the rest of the libraries which we decided was not worth our time to work through now and maintain for future releases of MVC.