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);
})();
