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.
- #1865
- change `MutableObjectModelBinder` to ignore exact match in value providers
- had an incorrect assumption: don't want exact model name to match since
this binder supports only complex objects
- also ignored `BinderModelName`, value provider filtering, et cetera
- reduces over-binding e.g. `[Required]` validation within missing properties
also add more tests of #2129 scenarios
- #2129
- do not propagate results with `!IsModelSet`, allowing empty prefix fallback
- adjust `ComplexModelDtoModelBinder` to at least fake-bind all properties
- default values not consistently picked up otherwise
nit: correct 2 test names in `KeyValuePairModelBinderTest`
- use named parameters more often
- add more comments about returned `ModelBindingResult`
- clean up `ModelBindingResult` doc comments
- cleanup `using`s
Nits:
- cleanup trailing whitespace
- change `retVal` -> `result` in `KeyValuePairModelBinderTest`
- Updated some naming bits that were still using the ViewStart name.
- Updated MvcRazorParserTests to test more cases of the parser, especially with @tagHelperPrefix.
#2110
- Any Action<ITagHelper, ViewContext> can be registered in DI to allow setting of tag helper properties after any [Activate] properties are set but before their bound from the source document and the tag helper is executed
- Removed previous tag helper options as initializers is the way to do this now
- #1689
- #2162
- see issues aspnet/DependencyInjection#193 and #1612
- use `TryAdd()` in `MvcServices` for the `IAssemblyProvider`
Move `ApplicationBasePath` handling into `RazorPreCompileModule`
- restores view precompilation in functional tests of sample sites
- if we need this, others will as well
- override `IApplicationEnvironment` but get folder from `ProjectContext`
- also remove remaining `IServiceProvider` implementations in this code
test fixes:
- simplify `IApplicationEnvironment` override
- move override logic into `TestHelper.CreateServer()` methods
- remove `LoggerFactory` setup
- does not seem to require special-casing
- remove unused `ITestConfigurationProvider` / `TestConfigurationProvider`
- remove `TestAssemblyProvider` classes
- no longer required
- remove `ReplaceCallContextServiceLocationService` test helper
- change MVC sample to fully-qualify config.json path
- avoids `ReplaceCallContextServiceLocationService` need in `MvcSampleTests`
- no longer required for other tests
nit: remove unused `_serviceProvider` and constructor overload in `RazorPreCompiler`
- work around aspnet/DNX#1361 and inconsistent dev boxes (from previous fix attempts)
- had inconsistent case in test/WebSites and test/WebSites/ConnegWebSite
- ConnegWebsite -> ContentNegotiationWebSite
- RazorInstrumentationWebsite -> RazorPageExecutionInstrumentationWebSite
- RazorViewEngineOptionsWebsite -> RazorEmbeddedViewsWebSite
nits:
- sort dependencies in functional test project.json
- correct a few readme.md files
- compiler given `ApplicationName`, not `ApplicationBasePath`
- @pranavkm wrote the tests prior to 64ddbe0160
nit: rewrap long line introduced in prior commit