- #EngineeringDay
- Total replaced: 660 Matching files: 270 in *.cs
- Total replaced: 250 Matching files: 32 in all other files
- Total replaced: 22 Matching files: 8 in a few stragglers
Did not change files under following directories
- test\Microsoft.AspNet.Mvc.Razor.Host.Test\TestFiles\Output
- test\Microsoft.AspNet.Mvc.FunctionalTests\compiler\resources
- test\WebSites\TagHelpersWebSite
(Razor generates trailing whitespace in a case or two)
IActionConstraint follows a provider model similar to filters. The
attributes that go on actions/controllers can be simple metadata markers,
the 'real' constraint is provided by a set of configurable providers. In
general the simplest thing to do is to be both an
IActionConstraintMetadata and IActionConstraint, and then the default
provider will take care of you.
IActionConstraint now has stages based on the Order property. Each group
of constraints with the same Order will run together on the set of
actions. This process is repeated for each value of Order until we run out
of actions or run out of constraints.
The IActionConstraint interface is beefier than the equivalent in legacy
MVC. This is to support cooperative coding between sets of constraints
that know about each other. See the changes in the sample, which implement
webapi-style overloading.
This change removes WebAPI-style method parameter overloading and the
automatic mapping of 'unnamed' actions based on method names. For all
practicaly purposes, this change restores the MVC5 behavior for action
selection.
WebAPI-style overloading will be brought back in the future via a set of
opt-in constructs.
The default implementation has a safe race, and does not allow for action description addition at runtime.
It can be replaced with an implementation that can reload.
Consumers of the new service that do extra caching are now responsible to look at the version and change the implementation.
Treat actions with a dynamic constraint or httpmethod constraint as
'better' than those with just route constraints.
This is the first criteria used to filter down the 'best' match, so it's
applied before parameter-arity.
This follows a similar pattern to html helpers - a minimal basis interface
that performs the main functionality, and a set of extension methods that
make up the rich API.
* Modify ReflectedActionInvoker to model bind parameters
* Introduce IBodyReader for reading request bodies
* Introduce types for per-action-context specific binders, value providers
and body readers