Updated the naming to follow guidelines, and set the default for 2.0
apps to false. Note that I inverted the naming, which means that I had
to invert the logic in a few places.
Related to issue [Fixes#6858] Changes to MvcOption's settings (SuppressInputFormatterBuffering & AllowBindingUndefinedValueToEnumType) are not taking affect
- #5502
- support thousands separators for `decimal`, `double` and `float`
- add tests demonstrating `SimpleTypeModelBinder` does not support thousands separators for numeric types
- add tests demonstrating use of commas (not thousands separators) with `enum` values
- #6076
- add resources and accessors specifically for the element / parameter cases
- avoid `metadata.GetDisplayName()` where possible
- fill in the `ValidationContext` that `ValidatorObjectAdapter` uses
- e.g. `Validate_NestedComplexType_IValidatableObject_Invalid()` test fails without this
Possible future work:
- improve error message used for `ModelMetadata.IsRequired` elements and parameters
- use something besides the type for `ValidationContext.DisplayName` of elements and parameters
nits:
- trailing whitespace
- use more `out var`
- #5642
- lazy-load `ValidationEntry.Model`
- avoids `Exception`s when moving to a property that will not be validated
nits:
- remove duplicate code in `ValidationVisitor`
- clarify "all properties of" doc comments
- also add missing `<param>` doc in `ViewDataInfo`
- #3918
- precompute size of `StringBuilder` in `ExpressionHelper`
- reduce `string` allocations in `ViewDataEvaluator`
- also get rid of `Enumeration` state machines
- reduce the size of a few objects; use more expression-valued properties
- e.g. don't store `_modelType` in `ModelExplorer`
- add `EmptyArray<TElement>`; make empty arrays consistently `static`
- avoid `string.Split()` in HTML and tag helpers
nits:
- make `ExpressionHelperTest` tests more stringent
- correct `Message` for an `ArgumentNullException`
- remove excess `using`s in classes I touched (but often ended up leaving otherwise unchanged)
- improve doc comments
- remove `ToString()` call on a `string`
- avoid encoding `string.Empty`
- fix test file name
- remove useless variables
- correct spelling
- improve whitespace
- #4988
- preserve whitespace as the setting demands
- correct previous `string.IsNullOrEmpty()` call to match previous `ValueProviderResultExtensions.ConvertTo()` use
- short-circuit other `string`-to-`string` conversions (as `ValueProviderResultExtensions.ConvertTo()` does)
- correct documentation of `ConvertEmptyStringToNull` properties
- add more tests of these scenarios and remove duplicate `BindModel_ValidValueProviderResult_ConvertEmptyStringsToNull()` test
- #4690
- move `ModelBindingMessageProvider` init from `DefaultBindingMetadataProvider` to `DefaultModelMetadata`
- in addition to avoiding error cases, this removes some boilerplate
- add specific errors to `BodyModelBinderProvider`, `CompilerCache`, `CompositeViewEngine`, `ModelBinderFactory`,
and `ObjectResultExecutor`
- `DefaultRazorViewEngineFileProviderAccessor.FileProvider` now a `NullFileProvider` in empty case
This change to ModelBinderFactory makes the caching much more aggressive,
by caching all non-root binders. There's some trickiness here around
making sure we have the right behavior when all providers return null. See
the tests and comments.
I also kept the change I made for a temporary workaround to use a
dictionary rather than a "stack" for cycle breaking. This seems like an
overall improvement in clarity.
- #4652
- previously ignored for top-level models
- `ModelBinderProviderContext.BindingInfo` is now never `null`
- similarly, use type metadata (as well as parameter info) for `ModelBindingContext.BinderModelName`
- previously ignored when overridden in `ControllerArgumentBinder`
This change simplifies a bunch of code and fits more in line with the
current design of model binding.
Now, a model binder only has to do anything if it was successful.
'return' is enough to indicate failure.
We want this change to avoid MVC eagerly reading the form. This is good
for general perf and also for scenarios where you want read the body
yourself (large file uploads).
We DO have scenarios where you want to configure the value providers
per-request or also to change the limits on the value providers (form) so
it's worth keeping these around on the context.