So here'
s a binding behavior in ASP.NET MVC that I didn't really get until today: HtmlHelpers controls (like .TextBoxFor() etc.) don't bind to model values on Postback, but rather get their value directly out of the POST buffer from ModelState. Effectively it looks like you can't change the display value of a control via model value updates on a Postback operation. To demonstrate here'
s an example. I have a small section in a document where I display an editable email address: This is what the form displays on a GET operation and as expected I get the email value displayed in both the textbox and plain value display below, which reflects the value in the mode. I added a plain text value to demonstrate the model value compared to what'
s rendered in the textbox. The relevant markup is the email address which needs to be manipulated via the model in the Controller code. Here'
s the Razor markup: <div class="fieldcontainer">
<label>
Email: <small>(username and <a href="http://gravatar.com">Gravatar</a> image)</small>
</label>
<div>
@Html.TextBoxFor( mod=> mod.User.Email, new {type="email",@class="inputfield"}) @Model.User.Email
</div>
</div>
So, I have this form and the user can change their email address. On postback the Post controller code then asks the business layer whether the change is allowed. If it'
s not I want to reset the email address back to the old value which exists in the database and was previously store. The obvious thing to do would be to modify the model. Here'
s the Controller logic block that deals with that:// did user change email?
if (!string.IsNullOrEmpty(oldEmail) && user.Email != oldEmail)
{
if (userBus.DoesEmailExist(user.Email))
{
userBus.ValidationErrors.Add("New email address exists already. Please…");
user.Email = oldEmail;
}
else
// allow email change but require verification by forcing a login
user.IsVerified = false;
}… model.user = user;
return View(model);
The logic is straight forward - if the new email address is not valid because it already exists I don't want to display the new email address the user entered, but rather the old one. To do this I change the value on the model which effectively does this:model.user.Email = oldEmail;
return View(model);
So when I press the Save button after entering in my new email address (
[email protected]) here'
s what comes back in the rendered view:
Notice that the textbox value and the raw displayed model value are different. The TextBox displays the POST value, the raw value displays the actual model value which are different.
This means that MVC renders the textbox value from the POST data rather than from the view data when an Http POST is active.
Now I don't know about you but this is not the behavior I expected - initially. This behavior effectively means that I cannot modify the contents of the textbox from the Controller code if using HtmlHelpers for binding. Updating the model for display purposes in a POST has in effect - no effect.
(Apr. 25, 2012 - edited the post heavily based on comments and more experimentation)
What should the behavior be?
After getting quite a few comments on this post I quickly realized that the behavior I described above is actually the behavior you'd want in 99% of the binding scenarios. You do want to get the POST values back into your input controls at all times, so that the data displayed on a form for the user matches what they typed. So if an error occurs, the error doesn't mysteriously disappear getting replaced either with a default value or some value that you changed on the model on your own. Makes sense.
Still it is a little non-obvious because the way you create the UI elements with MVC, it certainly looks like your are binding to the model value:@Html.TextBoxFor( mod=> mod.User.Email, new {type="email",@class="inputfield",required="required" })
and so unless one understands a little bit about how the model binder works this is easy to trip up. At least it was for me. Even though I'm telling the control which model value to bind to, that model value is only used initially on GET operations. After that ModelState/POST values provide the display value.
Workarounds
The default behavior should be fine for 99% of binding scenarios. But if you do need fix up values based on your model rather than the default POST values, there are a number of ways that you can work around this.
Initially when I ran into this, I couldn't figure out how to set the value using code and so the simplest solution to me was simply to not use the MVC Html Helper for the specific control and explicitly bind the model via HTML markup and @Razor expression:
<input type="text" name="User.Email" id="User_Email" value="@Model.User.Email" />
And this produces the right result. This is easy enough to create, but feels a little out of place when using the @Html helpers for everything else. As you can see by the difference in the name and id values, you also are forced to remember the naming conventions that MVC imposes in order for ModelBinding to work properly which is a pain to remember and set manually (name is the same as the property with . syntax, id replaces dots with underlines).
Use the ModelState
Some of my original confusion came because I didn't understand how the model binder works. The model binder basically maintains ModelState on a postback, which holds a value and binding errors for each of the Post back value submitted on the page that can be mapped to the model. In other words there'
s one ModelState entry for each bound property of the model. Each ModelState entry contains a value property that holds AttemptedValue and RawValue properties. The AttemptedValue is essentially the POST value retrieved from the form. The RawValue is the value that the model holds.
When MVC binds controls like @Html.TextBoxFor() or @Html.TextBox(), it always binds values on a GET operation. On a POST operation however, it'll always used the AttemptedValue to display the control. MVC binds using the ModelState on a POST operation, not the model'
s value.
So, if you want the behavior that I was expecting originally you can actually get it by clearing the ModelState in the controller code:ModelState.Clear();
This clears out all the captured ModelState values, and effectively binds to the model. Note this will produce very similar results - in fact if there are no binding errors you see exactly the same behavior as if binding from ModelState, because the model has been updated from the ModelState already and binding to the updated values most likely produces the same values you would get with POST back values.
The big difference though is that any values that couldn't bind - like say putting a string into a numeric field - will now not display back the value the user typed, but the default field value or whatever you changed the model value to.
This is the behavior I was actually expecting previously. But - clearing out all values might be a bit heavy handed. You might want to fix up one or two values in a model but rarely would you want the entire model to update from the model.
So, you can also clear out individual values on an as needed basis:if (userBus.DoesEmailExist(user.Email))
{
userBus.ValidationErrors.Add("New email address exists already. Please…");
user.Email = oldEmail;
ModelState.Remove("User.Email");
}
This allows you to remove a single value from the ModelState and effectively allows you to replace that value for display from the model.
Why?
While researching this I came across a post from Microsoft'
s Brad Wilson who describes the default binding behavior best in a forum post:
The reason we use the posted value for editors rather than the model value is that the model may not be able to contain the value that the user typed. Imagine in your "int" editor the user had typed "dog". You want to display an error message which says "dog is not valid", and leave "dog" in the editor field. However, your model is an int: there'
s no way it can store "dog". So we keep the old value.
If you don't want the old values in the editor, clear out the Model State. That'
s where the old value is stored and pulled from the HTML helpers.
There you have it. It'
s not the most intuitive behavior, but in hindsight this behavior does make some sense even if at first glance it looks like you should be able to update values from the model. The solution of clearing ModelState works and is a reasonable one but you have to know about some of the innards of ModelState and how it actually works to figure that out.© Rick Strahl, West Wind Technologies, 2005-2012Posted in ASP.NET MVC
Tweet
!function(d,
s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");
(function() {
var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
po.src = 'https://apis.google.com/js/plusone.js';
var
s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(po, s);
})();
