Opinionated Input Builders for ASP.Net MVC – Part 4 the Partial View Inputs

This is the forth part of the series. 

Given this form that is generated by the input builders the partials for each data type of the Model are selected by the builder based on a simple convention.


Each partial control is selected using the following convention:

  1. The type of the property is used to find a Partial View by the same name.
  2. If the partial does not exist in the /Views/Shared/ directory it is pulled from an embedded resource from the Input Builder assembly.  This allows you to override the conventions of the framework with your own.
  3. If a PartialView Attribute is applied to a property it is used to override the previous conventions.
  4. Display a partial using a Chained Method on the Input() method UsingPartial( partialName )

Looking at the types of the model you can see that the Enum partial will render a Select element by default.  The PartialView(“RadioButtons”) attribute was applied to override the default and have the build render the RadioButtons.aspx partial view.



This is an example of using the Chained Method override instead of using an attribute based approach.


This convention of utilizing the partial views allows the separation of concerns (SoC) of the markup from the conventions which determine which partial to render.

What if you do not like the convention ?????   Each part of the UI model is extensible.  There are two conventions that are at play here.  The selection of the partial view and the selection of the data that is used by the controls to display the possible selections.  This is shown for the enum data types which allows the select and radio button inputs to display a list of possible values. 


The ModelPropertyFactory class calls two methods to execute the conventions.  The ParialNameConvention and ModelPropertyBuilder by using the static Func fields this will allow your project to define your own conventions if you do not like mine.  This is an important extensibility point that gives the great flexibility to this approach.  There are conventions like this for each of the elements used within the partials. 


About Eric Hexter

I am the CTO for QuarterSpot. I (co)Founded MvcContrib, Should, Solution Factory, and Pstrami open source projects. I have co-authored MVC 2 in Action, MVC3 in Action, and MVC 4 in Action. I co-founded online events like mvcConf, aspConf, and Community for MVC. I am also a Microsoft MVP in ASP.Net.
This entry was posted in Asp.Net, Asp.Net MVC, CoC, mvccontrib. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Mihai

    This is better ;) way better thanks for the change in specifying the partial to be used

  • @Mihai I had the support in there, I just struggle with how to explain the various way to put all of this together. I could see this same model apply to all of the attributes.. but the converse is that if you were to use say a validation framework that was attribute based and you already specified a Required attribute than I would like to just reuse that rather than specifying in the view that the property is required… it is a tough balance to deal with.

  • BY adding another InputBuilder HiddleField.aspx, which uses the HiddenField.Master master page, you could then call

    < %=Html.Input(c => c.UserID).UsingPartial(“HiddenField”)%>

    If you wanted to show non-guid values (ints) in a hidden field.

  • mendicant

    I really like how it looks so far. I guess the only thing that bothers me is that maybe you’d want to use a strongly typed enum like InputBuilderPartial.RadioButtons and InputBuilderPartial.DatePicker instead of just “RadioButtons” and such.

    I can see a lot of interesting things coming from this though.

  • @mendicant the problem with using enums is that there would be some basic partials that are provided as part of this project but most project would add additional partials… say a set that do a lot of ajax stuff. AutoCompletes, Date or Time Pickers… So the problem with enums is that the framework does not allow enums to be inherited. So I think you could implement an enum that is project specific to eliminate the strings.. I could add that to my sample project.

  • Is it posibble to adding Hidden method within IInputSpecification interface, so we can easily hide value instead of create new partial view ?

  • Oh well under the hood the hidden method would delegate to a partial view. But that is what I am using for the Guid.aspx partial view now. It makes me think that rather than having the partial views named after the data types that they should be named after the ui controls. Than the convention would do the translation between the type to control to render it. I think this would really come up for integers. I could see them being used as hidden values slider controls and up down controls.

  • How would you accomplish the requirement of selecting radio button “One” should update the list of availble items in drop down list x?

  • Interesting the use of the partial renderer, I’ve been using it to render relation between properties, your implementation is wonderful.

    What if I need to display a dropdown box from, let’s say it, a repository? for example, the School property from Student needs to display a drop down list of schools taken from the SchoolRepository?

  • @Christian, you would implement your own DefaultConventions.ModelPropertyBuilder. In order to create values for your drop down you would add your own way to pull values based on the School PropertyType.