-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Action argument of IList<T> will be bound as Null instead of an empty List<T> #1579
Comments
What are the side effects here, and how is it different from MVC 5/Web API? |
The problem is since today CollectionModelBinder returns false, the is it different from MVC 5/Web API? |
@harshgMSFT please provide concrete repro for what is going to break. If you think this is critical for Beta3 milestone please raise a flag |
Ok .. sorry about not including a code sample : here is the actual issue ( after the Uber dust has settled 😄 ). public class HomeController : Controller
{
public void Action(IList<Model> model)
{
// Does something.
}
public override void OnActionExecuting(ActionExecutingContext context)
{
// context.ActionArguments["model"] is null here.
}
} and consider a URL like so :
With no value provider having a value for Model or its properties, what happens is the model object created is null. This is because This is contrary to what what we do with models in MVC 6.0. (we always create them). This is not a MUST fix as the user scenario is not broken but this provides an inconsistency in the system. |
We just ran into this in our project and broke a core assumption we had about MVC. In the beta 3 code, we had different behavior whether an action array parameter was null (when the param was not on the URL) or empty (the param is on the URL but empty). When we changed to beta 4, the array parmeter is always empty whether you specify anything on the URL or not. This caused a bug in our code. We've updated our code based on the new behavior, but wanted to let you know that this is a change that broke compat with older versions of MVC. |
@bgeihsgt we need to confirm the MVC 5 So, we'll make a call here and pick back-compatibility or consistency. Either way you'll see a resolution on this issue. If the result is a further change, we'll also use the Announcements repo. |
This change treats 'top-level' collection-type models similarly to top-level POCO model - namely that they will always be instantiated even if there's no data to put inside.
This change treats 'top-level' collection-type models similarly to top-level POCO model - namely that they will always be instantiated even if there's no data to put inside.
This change treats 'top-level' collection-type models similarly to top-level POCO model - namely that they will always be instantiated even if there's no data to put inside.
Today CollectionModelBinder returns false if a value provider cannot provide a value, it is the mutable object binder which creates a model for it.
Since it is the
CollectionModelBinder
which is responsible for binding collections, it should be the one which creates empty object and not let it slip for other model binders.The text was updated successfully, but these errors were encountered: