This change removes a layer of abstraction. These validators now just do
what they do now without creating a bunch of intermediate objects.
ModelClientValidationRule has been removed, and client validations
manipulate the attributes collection of a tag directly.
* 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.
Use x-forwarded-for validation to restrict other forwarders.
Rename OverrideHeaderMiddleware to ForwardedHeadersMiddleware.
Fix tests
Fix package version.
- 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`
This change 'flattens' a TagHelperOutput when writing it out to an
HtmlTextWriter. This is a beneficial perf change because more often than
not the thing being written to is a ViewBuffer in Razor, which uses pooled
memory. This allows us to 'join' islands of pooled ViewBuffer memory back
into the main buffer instead of keeping them wrapped up in a
TagHelperOutput or TagHelperContent.
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.
Hao Kung
N. Taylor Mullen
Pranav K
Brennan
Ryan Nowak
Derek Gray
ryanbrandenburg
Chris R
Stephen Halter
Ajay Bhargav Baaskaran
jacalvar
Doug Bunting
Pavel Krymets
SteveSandersonMS
Ben Adams