- #2969
- add `ModelBindingMessages` for configuration and `IBindingMetadataProvider` overrides
- use `interface` to avoid `new` oddities when adding a setter to an `abstract` property
- add `IModelBindingMessages` to `ModelMetadata` for use in rest of the product code
- plumb the various bits through the system
- add integration tests using a custom `IBindingMetadataProvider`s to override messages
nits:
- remove unused resources
- use `AttemptedValue` and not `model` in `SimpleTypeModelBinder`
This change moves the responsibility for saving TempData into a filter,
which is registered with other View features. This moves TempData into the
ViewFeatures package.
ActionResults which require TempData to be kept use a new marker interface
which is handled by the filter.
- #2705
- add `JQueryFormValueProvider` and `JQueryFormValueProviderFactory`
- carry some code forward from MVC 5; correct to follow current coding guidelines
- refactor `ReadableStringCollectionValueProviderTest` into abstract `EnumerableValueProviderTest`
- enables reuse in new `JQueryFormValueProviderTest`
- also run these tests in `CompositeValueProviderTest`
nits:
- do not create a duplicate `CompositeValueProvider` instance in `Filter()`
- correct garbled sentence in `IBindingSourceValueProvider` doc comments
- simplify `FormValueProviderFactoryTest` (no need for Moq) and correct test name
- correct test class / file names
- `CompositeValueProviderTests` -> `CompositeValueProviderTest`
- `FormValueProviderFactoryTests` -> `FormValueProviderFactoryTest`
This change removes the validation that forces an OutputFormatter to set
an encoding, so that you can use the OutputFormatter base class for
non-text.
The check that we had would pretty much only be hit when you
didn't have any SupportedEncodings. If you have anything in
SupportedEncodings, then one of them will be picked as a default. So
removing the check is to do, because for a text-based formatter you'd
never run into this issue in the first place.
- part I of II for #2445 (with a duplicate code PR to follow)
- needed for #2445 because new `ModelState` entries for values will make inconsisteny worse
- change `BodyModelBinder` to use same keys for all `ModelBindingResult`s and `ModelState` entries
- return fatal error result if formatter adds an error to `ModelState`
- update potential callers to avoid avoid ignoring `IsFatalError`
- fix test attempting to serialize all of `ModelState`
- will be borked with additional `RawValue`s in state
- fix two other tests that serialized `ModelState` but checked only `IsValid`
nits:
- address minor inconsistencies in `ModelBindingContext`
- use `System.Reflection.Extensions` package a bit more, where it's already referenced
- remove some unused resources
This is the first step is some more refactorings to come in the future
with the goal of making MVC less monolythic. This makes the core of MVC
more reusable and more in line with the design of other vNext platform
components.
With this change, Mvc.Core contains just the minimal guts needed to build
a working app.
- Action Discovery
- Action Invoker
- Filters
- ObjectResult
- Model Metadata
- Model Binding
- Formatters
- Validation System
And yes, we are aware of the irony of 'minimal MVC' not including the view
system. The idea is that this is the kernel of an MVC app, and anything
real is layered on top.
The most noticable impact of this change is that MvcOptions has been blown
apart into more managable chunks. See the various ConfigureMvc*** methods.
The new Mvc.Extensions package is a placeholder while we evaluate and tune
the new definitions. Expect more changes as features are move to their own
packages, and in some case their own repositories.
For now there is no experience to bootstrap an Mvc.Core app. That's coming
next.
- only use MVC error message when `[BindRequired]` is violated
- update that error message to more clearly describe the problem
- enable all tests skipped due to dupe bug #2493
- update expectations of a few tests using the old messages
nits:
- rename `ModelBinding_MissingRequiredMember` to `ModelBinding_MissingBindRequiredMember`
- remove `<param>` description of removed `requiredValidator` parameter
- remove unused `MutableObjectModelBinderTest.GetRequiredValidator()`
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).
services
* Added WithControllersFromServiceProvider that replaces the default
controller activator with a service based one.
* Move activation to DefaultControllerFactory
* Modify [Activate] behavior so that it no longer activates services. Use
[FromService] attribute to hydrate services
Fixes#1707
This is a major refactor of how IBinderMetadata interacts with model
binders and value providers. We're doing this to support better
extensibility for metadata in ApiExplorer.
You'll notice a bunch of deleted code in DefaultApiDescriptionProvider
that maps metadata marker interfaces to a fixed list of Api sources. This
is replaced now with IBindingSourceMetadata - which also replaces the
hierarchy of marker interfaces. Now user code can create an arbitrary
binding source and have a consistent API for model-binders,
value-providers and full-visibility in ApiExplorer as
well.
Additonally, there's some error checking in place that better enforces the
constraints we already have in the system. IE you can't create a 'greedy'
model binder that uses value-provider data.
Two additional enhancements are planned for followup PRs:
1. Add a BindingSource property to model-metadata. This will remove some
duplication, but I want to delay it because it would touch another 10 or
so files.
2. Add an extensibility interface for our 'special' model binders like the
file binder so these can show up in ApiExplorer as well.
- #439 (2 of 3)
- correct namespaces
- correct `Resources` class and member names; add new resources
- add `RequestServices` property to `ClientModelValidationContext`
- adjust to modern `IUrlHelper` API
- add `IClientModelValidator` support in `DataAnnotationsModelValidator`
- move previously-unused `StringSplit()` to `RemoteAttribute` and rename
- rewrite `RemoteAttributeTest`
- improve test method names
Reduce number of `[Remote]` constructor overloads
- remove `AreaReference` enum and related `[Remote]` constructor overload
- use `null` or empty `string` as explicit reference to the root area
- generally reduce parameter validation; match `UrlHelper`
Cleanup
- correct Engineering Guidelines violations
- especially: add doc comments
- correct spelling error in `_additonalFieldsSplit`
nits:
- minimize `null` checks in `AdditionalFields`
- make `GetClientValidationRules` `virtual`; some subclasses use `new` today
- add tests of `DataAnnotationsModelValidator.GetClientValidationRules()`
- remove `builder.ToString()` calls since it appears
https://roslyn.codeplex.com/workitem/246 has been resolved or Moq has
worked around that issue.
This change makes ApiDescription and ApiParameterDescription aware of all
of the new features we built into model binding for enhanced DTO support
(uber-binding).
The main change is that instead of sticking just to the declared
parameters on the action itself, we now traverse model metadata and break
the parameters down based on their logical data source.
This means that a model like the below will yield 3 parameters:
public class ProductChangeCommandDTO
{
public int Id { get; set; }
[FromBody]
public ProductDetails Changes { get; set; }
[FromQuery]
public string AdminComments { get; set; }
[FromServices]
public IProductRepository Repository { get; set; }
}
The 'Repository' will be hidden, as it's not related to user input.
Additionally, we treat different sources differently. In the
above example, 'Changes' is from the body and will be treated as a
leaf-node.
However if you use nested DTOs that are bound from the query string (using
[FromQuery]) or similar, we'll recursively explore to find as much
structure as possible.
This information is combined with data from the route template to give a
much more complete picture than we ever could in the past for parameters,
especially when DTO/Command pattern is used.
This is a new filter stage that surrounds the existing model binding,
action, and result parts of the pipeline. Resource Filters run after
Authorization Filters.
The other major change is to support one of the primary scenarios for
Resource Filters. We want a filter to be able to modify the inputs the
model binding (formatters, model binders, value providers, etc) -- this
means that those changes need to be held on a context object and preserved
so that they can be used in the controller.
So, IActionBindingContextProvider is removed - the ActionBindingContext
will be created by the invoker. For now it will be part of the action
context.
This change enables some compatibility scenarios with MVC 5 by expanding
the set of legal ways to configure attribute routing. Most promiently, the
following example is now legal:
[HttpPost]
[Route("Products")]
public void MyAction() { }
This will define a single action that accepts POST on route "Products".
See the comments in #1194 for a more detailed description of what changed
with more examples.
- `ViewDataDictionary<TModel>` constructors now pass `typeof(TModel)` to base
`protected` constructors
- move type compatibility checks into base `ViewDataDictionary`
- remove `ViewDataDictionary<TModel>.ModelMetadata` override
- don't retrieve `ModelMetadata` twice in a single constructor invocation
- remove newly-unused `protected` properties and use `private` fields in copy
constructors
Address longstanding problems found (see #1466)
- avoid reusing `ModelMetadata` after `Model` value changes
- reset `ModelMetadata` backing field in `Model` setter
- `Model` and `ModelMetadata.Model` could previously get out of sync
- carry `ModelMetadata` forward from an outer scope only if `Model` matches
- previously two scopes could have different `Model` values but share their
`ModelMetadata` (and `ModelMetadata.Model`)
- related to previous item but didn't require `Model` setting; switching
to a property of the same type as containing `Model` was enough
- avoid NRE if `ViewDataDictionary<int>.Model` is read before it's written
- problem affected all non-`Nullable` value types
- `ViewDataDictionary.ModelMetadata` setter should throw if value is `null`
nits:
- add and reword doc and code comments
- `ViewDataDictionary<TModel>` constructors should only inherit base's
parameter descriptions; have more information in the derived class
- make a few `ViewDataDictionary` properties get-only
- clean up `using` statements in `ViewDataDictionary<TModel>`
- make two constructors `internal`
This change adds the concept of a full-name to viewcomponents. View
components can be invoked using either the short name or long name. If the
provided string contains a '.' character, then it will be compared against
full names, otherwise it will be matched against short names only.
The short name is used for view lookups.
If the name is explicitly set via ViewComponent attribute, then the full
name is the name provided. The short name is the portion of the name after
the last '.'. If there are no dots, then the short name and full name are
the same.
If the name is not set explicitly, then it is inferred from the Type and
namespace name. The short name is the Type name, minus the 'ViewComponent'
suffix (if present). The full name is the namespace of the defining class,
plus the short name.
- includes new `RazorPage<TModel>.CreateModelExpression<TValue>()` method
- #1240
nit:
- regenerating the resources reordered Microsoft.AspNet.Mvc.Core's Resources.designer.cs
Ryan Nowak
Ajay Bhargav Baaskaran
Cesar Blum Silveira
unknown
Doug Bunting
Pranav K
N. Taylor Mullen
Kirthi Krishnamraju
sornaks
Mugdha Kulkarni
Harsh Gupta
Anthony Sneed
jacalvar