- Part 1 – Overview
- Part 2 – the Label
- Part 3 – the Source Code
- Part 4 – the Partial View
- Part 5 – the Required Field Indicator
- Part 6 – the Performance
- Part 7 – the Performance Take 2
- Part 8 – the AutoForm
It has taken a while to really understand how different pieces and ideas can fit together to give a concise and productive form input helpers for the asp.net mvc framework. I have pulled together this idea from the following sources:
- “opinionated input builders” that Jeremy Miller and Chad Myers presented at the Kaizen Conference in Austin last year,
- The work that Headspring Systems (Jimmy Bogard and Matt Hinze) has done with that concept on some of our big projects.
- Brad Wilson’s sample of how Dynamic Data Could work on Asp.Net MVC
- Convention Over Configuration – Ruby on Rails and Jeremy Miller
- Creating partial views as aspx pages with their own nested master pages via Jeffrey Palermo
- The strongly typed helpers from MVC Contrib and the MVC Futures work that the MVC Team has put together.
Now that I have given credit to everyone who has helped me get to the point of understanding how to pull of these pieces together.
The Model comes first.
The goal of these control helpers is to reward you for developing MVC with the Model first. Yeah there is a reason that Model View Controller starts with the Model. Using the strongly typed views in the aspx view engine we can carry the type down to the control helpers with intellisense and then build html input control based on conventions for rendering specific CLR types to specific HTML output. Now my biggest problem with the ways that this has been attempted to date is that once helpers started to take on more mark up beyond the < input > tag it was hard to modify as that markup ended up being written in code rather than in a view file. This is where I abstracted the mark up and the logic to decide which markup to render so that there is a solution that is easy to maintain the markup and it is easy to add new conventions or change the conventions for how a particular type or model property is rendered to a control.
First here is an example of a model rendered in a strongly typed view and the markup used to create this. There are attributes applied to the model to add some specific control over how the UI is rendered. It is important to call out that in this case I have built a (view) Model specifically to represent a single view. I do not intend to reuse this model in another views. I think trying to get reuse out of models is a mistake in most circumstances, it is better to keep your model clean so that it represents exactly what you want for the View. Each of these attributes are used by my conventions to decide which Partial View to render.
This is the example of the view page which is rendering the view and the markup used to create this. The Html.Input uses the LamdaExpression syntax to declare which property needs and input.
It is important to call out that the Guid property is rendered as a Hidden input tag and that is why it does not show up in the UI. This is a model element that is used to carry state in the form between posts.
Walkthrough of the Html.Input( ) method
The syntax for calling into the input method uses a lamda expression like so….. This has full intelisense support.
The helper determines that since the Name is a string data type it decides by convention to render this property using the String.aspx partial view.
Here is the markup of the String.aspx partial view. As you can see it uses a Master Page to control how its label and input is rendered.
Here is the Field.Master Master Page this controls the layout of the input, label, example text, and validation message.
Follow me on RSS and Twitter