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.
This will help future generations maintain this class. Notice that the
protected methods that are going away all just call into another
extensibility point (other than the executor). If we need to we could make
that extensible in the future and then we have the same support with fewer
hooks and less complexity.
This change just rearranges some code in the argument binder with a mind
towards performance and clarity. We're removing a few Task<T>'s here as
well in certain cases, but not yet all of them. We additionally save a
dictionary in the case where you have bound properties.
Hopefully these changes break the code into more discrete and sensible
units without multiple levels of indirection without abstraction.
- Main 'driver' code
- BindModel
- ActivateProperty
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.
- #4339: remove non-recommended JSON formatter constructors
- affects `JsonInputFormatter`, `JsonOutputFormatter`, `JsonPatchInputFormatter`
- `JsonOutputFormatter` cleanup also impacts `JsonHelper`
- rename and make `SerializerSettingsProvider` class public; use it as appropriate
- #4409: make `SerializerSetings` properties get-only and `protected`
- affects `JsonInputFormatter`, `JsonOutputFormatter`
Recommended patterns:
- change `JsonSerializerSettings` values in `MvcJsonOptions` for almost all customizations
- find `JsonOutputFormatter` in `MvcOptions.OutputFormatters` when limiting per-result formatters
- start with `JsonSerializerSettingsProvider.CreateSerializerSettings()` when customizing a per-result formatter
* Remove IAssemblyProvider.
* Remove DefaultAssemblyProvider in favor of DefaultAssemblyPartDiscoveryProvider.
* Update AddMvcDnx to add the list of DNX discovered assemblies to the list of application parts.
* Added ViewComponentFeture and ViewComponentFeatureProvider to perform view component discovery.
* Changed view component discovery to use application parts.
* Changed ViewComponentDescriptorProvider to make use of Application parts.
* Added AddViewComponentsAsServices method on IMvcBuilder that performs view component
discovery through the ApplicationPartManager and registers those view components as
services in the service collection. Assemblies should be added to the ApplicationPartManager
in order to discover view components in them in them.
* Added ControllerFeature and ControllerFeatureProvider to perform controller discovery.
* Changed controller discovery to use application parts.
* Changed ControllerActionDescriptorProvider to make use of Application parts.
* Simplified AddControllerAsServices to not accept any parameter and perform
controller discovery through the ApplicationPartManager in the IMvcBuilder
and IMvcCoreBuilder. Assemblies should be added to the ApplicationPartManager
in order to discover controllers in them.
This change renames IPropertyBindingPredicateProvider to
IPropertyFilterProvider. The changes here are mostly renames of
parameters/variables from predicate -> propertyFilter. I did a
find+replace and left the term 'predicate' in some of the docs because it
refers to a predicate in the abstract sense.
This change also simplifies BindAttribute and removes support for type
activation.
This commit introduces application parts as a concept on MVC.
An application part is an abstraction that allows you to expose some
feature or corncern in a way that is decoupled from their underlying source.
Examples of this include types in an assembly, emdeded resources, files on
disk etc.
Application parts are configured during startup by adding or removing them from
the application part manager available as part of IMvcBuilder and IMvcCoreBuilder.
The application part manager provides the ability to populate features from the
list of available application parts by using a list of application feature providers.
Application feature providers are responsible for populating a given feature given a
list of application parts.
Examples of application providers can be a ControllerFeatureProvider
that goes through the list of application parts, sees which one of those parts exposes types,
determines which of those types are controller types, and adds them to a ControllerFeature
that holds a list of all the types that will be considered controllers in the application.
* Introduce ControllerAttribute and use it to mark base classes as controllers.
* Changed rules for controller discovery to:
* All controller types must be public, concrete, non open generic types.
* NotController attribute is not applied to any type oif the hierarchy.
* The type name ends with controller.
* Controller attribute is applied to the type or to one of its ancestors.
Ryan Nowak
jacalvar
Kiran Challa
mnltejaswini
Ryan Brandenburg
Kristian Hellang
Pranav K
Doug Bunting
Sebastien Ros
Pavel Krymets