Adds the set of CreateResponse/CreateErrorResponse extension methods that
return an HttpResponseMessage.
For the overloads that perform content negotiation they will access the
collection of MediaTypeFormatters through the shim options. Note that
CreateResponse and friends use the OLD formatters.
Also, HttpError and CreateErrorResponse assume ErrorDetail == false. Using
the shim you will not get detailed error messages unless you construct the
HttpError instance yourself.
This change adds a ModelBinder that can bind an HttpRequestMessage to an
action parameter.
This builds on an earlier change to construct and store the request
message in the HttpContext via an http feature.
This change adds a .Request property to the ApiController class that can
be used to access an HttpRequestMessage wrapping the HttpContext.
The HttpRequestMessage is stored in an http feature to make it accessible
to model binders and other infrastructure.
This change adds ApplicationModel conventions that can enable WebAPI
action conventions (verb mapping) and WebAPI overloading.
The conventions activate when a controller has a marker attribute.
ApiController has this attribute, so any ported code will automatically
opt-in.
Also ported some old tests for action selection to our new functional test
framework.
Adds an options class, as well as a default options setup that will
configure the default set of formatters.
Currently most of what options needs to do is a placeholder, but it later
do things like add ApplicationModelConventions, filters, formatters, model
binders, etc. Those will be added in follow up items.
This change includes the basic properties that we're providing for
compatability as well as some functional tests and unit tests that verify
that ApiController can be a controller class.
- Exposed internals from Mvc.Razor.Host to Mvc.Razor.Test so it can use the MvcRazorHost override that takes the IFileSystem.
- Added end-to-end code generation tests for TagHelpers with ModelExpression properties.
#1241
- Added an end-to-end test that verifies all content behaviors, interactions and functionalities of tag helpers.
- Added some common user scenarios to verify that the system works how we expect.
#1116
- We now new up TagHelper's, requiring them to have parameterless constructors.
- Added test to validate throwing.
- Removed existing tests that expected the constructor injection behavior.
#1303
- The TagHelperActivator enables dependency injection via properties and allows access to the ViewContext.
- This replaces the ICanHasViewContext mechanism that we had in place before.
- Added tests and fixed up existing to work with new format for providing ViewContext.
#1258
- includes new `RazorPage<TModel>.CreateModelExpression<TValue>()` method
- #1240
nit:
- regenerating the resources reordered Microsoft.AspNet.Mvc.Core's Resources.designer.cs
- The CreateTagHelper method is responsible for creating and activating TagHelpers.
- Added the support for requesting the ViewContext.
- Added tests to validate the tag helper creation mechanism.
#1104
- RazorPage now has the ability to use writing scopes to control where things are written.
- This enables RazorPages to use these writing scopes with TagHelpers. TagHelpers use them to buffer attributes that have C# contained within them and to also buffer content of TagHelpers whos ContentBehavior is Modify.
- Added RazorPage tests to validate their functionality.
#1102
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.
- only affects an extreme corner case: user sets `metadata.EditFormatString` then reads
`metadata.DisplayFormatString`
- an extreme case because `EditFormatString` is normally set only when
`DisplayFormatString` is set and, if set, it's to the same value
- happened to see this while updating `CachedDataAnnotationsModelMetadata` for this PR
nit: an -> a in an adjacent XML comment in `CachedDataAnnotationsModelMetadata`
Ryan Nowak
Harsh Gupta
Pranav K
YishaiGalatzer
N. Taylor Mullen
Hao Kung
Doug Bunting
Murat Girgin
sornaks
David Fowler
jacalvar