1

I have an action that looks like this

[HttpGet]
public ActionResult ChooseReplacementUser(int deletedUserId, int deletedDbUserId)
{
     return View(new ChooseReplacementUserVM());
    //alternatively
    //return View(new ChooseReplacementUserVM() { DeletedUserId = deletedUserId });
}

ViewModel

public class ChooseReplacementUserVM
{
    public int DeletedUserId { get; set; }
    public int DbUserId { get; set; }
}

I have tried some variations of this, but this but this is probably the most clear cut. When the model is just return (and no properties are set), the values for the model are 0 when breaking in the view. The problem is that after inspecting the Model, and the values are 0, i expect them to be 0, but for some reason ASP does some binding after this (Guessing something similar to Request.Parameters). when I check the source, the hidden field for DeletedUserId is now set to the value sent in the GET method.

This behaviour is very confusing and I would have accepted it to auto-bind to the VM (so that when i return a new instance of a ViewModel, the properties are auto bound to it when they have the same name, and when breaking in the view the value would be set to the VM), but not that the VM displays 0 and then when inspecting the html (and when posting the form) the value is 3369.

Get method, the html markup, then the source

This problem have been in the framework for a long time, but I just ran into it again today and I really want to know why this has not been fixed.

So, is this behaviour by design or is it a bug in the binding? If it's by design, I can not understand why some one would wan't this behaviour at all.

Binke
  • 897
  • 8
  • 25
  • 1
    The HtmlHelpers use the values from `ModelState` in preference to values from the model, and those values have been added to`ModelState` because your parameter names match exactly the property names. Refer the last part of [this answer](http://stackoverflow.com/questions/26654862/textboxfor-displaying-initial-value-not-the-value-updated-from-code/26664111#26664111) for an explanation of the behavior. –  Apr 14 '16 at 10:32
  • Thx @StephenMuecke! Different question but that answer actually explains this behaviour great detail – Binke Apr 14 '16 at 12:45

0 Answers0