Consider
public class Person
{
[FromBody]
public Address Address { get; set; }
}
public class Address
{
[Required]
public string Street { get; set; }
public int Zip { get; set; }
}
Request body { "Zip" : 12345 }
In this case the error key would be "prefix.Address.Street" (assuming there is a prefix because of additional metadata/positioning for/of the Person model).
public class Person
{
[Required]
public string Name { get; set; }
}
public void Action([FromBody]Person p)
{
}
Request body { }
In this case the prefix gets ignored and the error key is Name.
Please note this is so that we are compatible with MVC 5.0
public class Person
{
[Required]
public string Name { get; set; }
}
public void Action([FromBody][ModelBinder(Name = "prefix")] Person p)
{
}
public void Action2([FromBody][Bind(Name = "prefix")] Person p)
{
}
Request body { }
In both these cases (Action and Action2) the prefix gets ignored and the error key is Name.
This is a slight improvement from mvc, as in MVC the action parameter would be null.
The followup for this would be to fix#2416 -
This PR ignores the validation assuming that #2416 will address the issues and update the test.
NOTE: previous versions of mvc did not have property binding and hence there is no precedence in this case. For MVC and Web API it was possible to body bind an action parameter which used an empty prefix instead of a parameter name for adding errors to model state (In case of MVC if a custom prefix was provided, it failed binding from body i.e the parameter was null).
This change moves [BindingBehavior(...)] and friends into the model
metadata layer, and removes the reflection code from
MutableObjectModelBinder that was looking for them previously.
This change adds more information to ModelAttributes, so that metadata
providers can look at the attributes on the property and type separately
if so desired
This change introduces a new property to ModelMetadata called
IsBindingRequired, which specifies whether or not a model value must be
present on the wire during model binding.
[DataMember(IsRequired = true)] is currently the only thing that will set
this property.
Updated tests and documentation for clarity on the difference in meaning
between MM.IsRequired and MM.IsBindingRequired. Moved setting for
IsRequired to ValidationMetadata which is a better fit.
Also added functional tests for [BindingBehavior] and [DataMember] in
model binding because they were totally missing.
This change caches the actual model metadata instances. Some profiling
showed we didn't go far enough, we were allocating a lot of ModelMetadata
+ ModelPropertyCollection instances.
The DataAnnotationsMetadataProvider was setting the bool? IsRequired, all of the
time instead of only setting it to true when we found a RequiredAttribute.
So we never actually executed the fallback logic here. Found
this while working on removing some reflection code from the validator,
and wanted to split it out because it's simple.
This change removes reflection from validator providers, and instead
relies on cached metadata in in the modelmetadata.
In general this means that our MVPs don't need to cache anything, they
just look at the metadata and create what they need.
In the case of data-annotations, we update the model details provider to
add validation attributes to the modelmetadata. This would allow someone
to replace the DataAnnotationsValidatorProvider, but still use the
metadata in these attributes.
The change to the IModelValidatorProvider api (to use a context) is
intended to minimize allocations. Currently each validator provider needs
to return a list so you end up with N+1 lists (N validators + a final list
to compine them all). This change will let us just create the final list
(and a small context object). This is a very very high traffic API so it
seemed worth doing.
There's also some general massaging of namespaces and file locations.
Separates the MMP into two phases:
1). Creation of the ModelMetadata, discovery of properties and attributes
(reflection) is part of the MMP
2). Lookup of details based on attributes is now part of another phase,
and has its results cached.
Users can now implements and register an IFooMetadataProvider to customize
a single aspect of metadata (see how data annotations does it).
Harsh Gupta
Ryan Nowak
Ajay Bhargav Baaskaran