* Moved instantiation of view components into DefaultViewComponentActivator
* Introduced IViewComponentFactory to handling setup of new view component instances.
* Added a release method on IViewComponentActivator for handling tear down of view
component instances.
* Added a Release method to IControllerActivator
* Changed Create in IControllerActivator to take in a ControllerActionContext
* Move the check to determine if a controller can be instantiated into the controller activator.
* Move logic for disposing controllers into the controller activator and make release on the
controller factory delegate into the activator.
* Changed release methods to take in a controller context.
- have one test muted at the moment in our CI
- add `Reset()` action to the service, enabling `// Arrange` to bring `Index()` content to a known state
- add a couple more tests to `TagHelperSampleTest` covering the new action and empty `Index()` list
nits:
- use `ViewData`, not `ViewBag`
These changes are aimed at significantly improving the performance of
MVC/Razor when a large amount of content is in play or a large number of
TagHelpers are used.
A few issues addressed:
- Buffer sync writes after a flush has occurred so that we can write them
asyncronously. The issue is that an IHtmlContent can only do sync
writes. This is very bad for Kestrel in general. Doing these writes
async is better for our overall perf, and the buffer that we use for it
is from the pool.
- 'Flatten' ViewBuffers when possible. A page with lots of TagHelpers can
end up renting a ViewBuffer and only write 2-3 things into it. When a
ViewBuffer sees another ViewBuffer we can either steal its pages, or
copy data out and 'return' its pages. This lets us use 3-4 buffers for a
large Razor page instead of hundreds.
- #3215
- add new accessor properties to `IModelBindingMessageProvider` and plumb them through
- use in `ModelStateDictionary` when handling a `FormatException` or `OverflowException`
- use in `ValidationHelpers` when handling a `ModelError` with `null` `ErrorMessage`
- add new `ModelExplorer` parameter to `IHtmlGenerator.GenerateValidationMessage()`
- plumb through to `ValidationHelpers.GetModelErrorMessageOrDefault()`
Started from work @kichalla did on the `kiran/movemessages-to-messageprovider` branch in #3775.
nits:
- use helper methods more consistently in `HtmlHelper<T>`; slightly improves error checking
- remove unused `Resources` class from `Microsoft.AspNet.Mvc`
- make `ValidationHelpers` class `public`; already in `.Internal` namespace
- split `GetUserErrorMessageOrDefault()` in two; rename to `GetModelErrorMessageOrDefault()`
- fix some #YOLO wrapping
- aspnet/Razor#643 part 2: react to aspnet/Razor#653
- change test calls and delegates to include new parameter
- add tests specifically of the new feature
- add tag helpers using new feature to `TagHelpersTest` functional test
- note `HtmlEncoder`s used elsewhere e.g. in other `RazorPage` instances are unaffected
- i.e. changing one `RazorPage.HtmlEncoder` property only affects C# expressions in that page
Also simplify scope management, removing bizarre assertion when user does something odd.
nits:
- correct `// Act` and `// Act & Assert` content
- remove #YOLO wrapping
- #3386
- initialize comparison `HashSet` with unencoded values to ensure both are checked
- address perf and correctness issues in this code
- `context.Items[typeof(SelectTagHelper)]` entry read as `ICollection` but written as `IReadOnlyCollection`
- `IReadOnlyCollection` worse because it does not include `Contains()`, causing Linq use
- every `<option>` element recalculated the encoded values and created a `HashSet` to contain them
- add `CurrentValues` type to cache this `HashSet` in `context.Items`
- each `OptionTagHelper` created the additional `HashSet` even if `Value` was bound
This change adds a list of ApiRequestFormat objects to ApiDescription
object which include the content type and formatter for each supported
content type which can be understood by the action.
Computation is aware of the [Consumes] attribute via the
IApiRequestMetadataProvider metadata interface, and aware of Input
Formatters via the new IApiRequestFormatMetadataProvider interface.
This algorithm is essentially the same as what we do for
produces/output-formatters. We iterate the filters and ask them what
content types they think are supported. Then we cross check that list with
the formatters, and ask them which from that list are supported. If no
[Consumes] filters are used, the formatters will include everything they
support by default.
This feature and data is only available when an action has a [FromBody]
parameter, which will naturally exclude actions that handle GET or DELETE
and don't process the body.
jacalvar
N. Taylor Mullen
Doug Bunting
Pavel Krymets
Pranav K
Ryan Nowak
Brennan
Ajay Bhargav Baaskaran
Kristian Hellang
Derek Gray
ryanbrandenburg
John Luo
Ben Adams