- Changing HtmlHelper and HelperResult to implement IHtmlContent.
- Introducing BufferedHtmlContent.
- Making RazorPage handle only IHtmlContent and clearing out other types.
- Making StringCollectionTextWriter use BufferedHtmlContent so that it can be returned where necessary.
- Updating places which involve Write/Copy to pass in encoders.
- The encoders are currently not being used during write. But when HtmlString is modified to carry encode metadata, the encoder can be used for writing. This is a perf optimization and hence not a part of this change.
- Making TagHelperContent implement IHtmlContent.
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.
- Tested with a page containing 33% of invalid Ids which go through TagBuilder.CreateSanitizedId.
- Ran 10,000 requests with 20 in parallel and measured perf.
- Data before the change:
System.String allocated by CreateSanitizedId: 1.84 mb
System.Text.StringBuilder allocated by CreateSanitizedId: 1.68 mb
- Data after the change:
System.String allocated by CreateSanitizedId: 0.720 mb
System.Text.StringBuilder allocated by CreateSanitizedId: 0.560 mb
Around 60% improvement from the original case.
- Previously `ModelBindingResult.IsModelSet` would be set to true if type conversions resulted in empty => `null` values for ValueTypes. This resulted in improper usage of `ModelBindingResult`s creating null ref exceptions in certain cases.
- Updated existing functional test to account for new behavior. Previously it was handling the null ref exception by stating that errors were simply invalid; now we can provide a more distinct error.
- Added unit test to validate `TypeConverterModelBinder` does what it's supposed to when conversions result in null values.
- Added additional integration tests for `TypeConverterModelBinder`.
#2720
- Disabling tests which have corresponding bugs in mono.
- Fixing a few tests which do not handle *nix file system.
- Updating Travis configuration to use mono's alpha bits.
- Introducing PlatformNormalizer to normalize content across multiple platforms.
- Removed TaskHelper and refactored with ClosedGenericMatcher
- Removed TypeHelper
- Moved custom encodings to InputFormatter
- Moved ObjectToDictionary to PropertyHelper
- Removed respective tests and test projects
This is some low hanging fruit for reducing the number of resolves we have
per request.
DefaultHtmlGenerator: Lots of these are created by RazorPage. It needs
IUrlHelper, so scoped is the best we can do for now. For an example, on
the front page of our sample, 48 of these are created for each request.
48! This takes it down to 1-per-request.
JsonResult: Again, multiple created per request (12 for the sample). This
class is totally stateless, so we can get down to 0-per-request.
DefaultViewComponentInvokerFactory: Same story as JsonResult.
DefaultObjectValidator/MvcMarkerService/DefaultFilterProvider:
these are stateless and pretty much guaranteed to be used by every request.
Getting them off the table.
- was trying out rules matching frequest PR comments (then)
- did a manual scan to find new instances of same issues
- "" -> `string.Empty`
- `String` -> `string` and similar
- fill empty XML doc elements
- ignored `JsonPatchDocument<TModel>`; just too many empty elements
- corrected missing / extra / out-of-order `<param>` descriptions
- `xml-docs-test` detects incorrect external references but not these local issues
- #1514
- refactor `RazorCompilationService` to allow a test subclass that normalizes Razor file line endings
- add `TestRazorCompilationService` to `RazorPageExecutionInstrumentationWebSite`
- adjust line endings to match in `RazorPageExecutionInstrumentationTest`
- add `ignoreLineEndingDifferences: true` to `Assert.Equal()` calls
- responses on Windows can have a mix of line endings
- `git config` setting affects line endings in .cshtml (and baseline) files
- however MVC and Razor mix `Environment.NewLine`s into HTTP responses
- update `PrecompilationTest` to split response regardless of line endings
- update `ResourceFile` to normalize all source file streams to LF only
- ensures consistent checksums and line mappings
- change `MvcRazorHostTest` to expect new line mappings
- recreate baseline files to expect new checksums and literal line endings
- use verbatim strings in affected tests
- careful use of `Environment.NewLine` in expectations is now just noise
nits:
- add doc comments in `RazorCompilationService`
- correct `TagHelpersTest` name to match containing file
- avoid incorrect `using` removal when `GENERATE_BASELINES` is not defined
- remove unnecessary `ResourceFile` normalization of output files
- cleanup duplicate code now that #2445 is fixed
- update unit tests using old `ModelBindingContext` setups
- fix (just) one integration test where `MutableObjectModelBinder` incorrectly calculated
`isTopLevelObject` and returned a non-`null` model
- undo temporary changes in `BodyModelBinderTests` due to increased reliance on incorrect
`isTopLevelObject` in #2445 fix
nits:
- combine tests that are now duplicates
- beef up coverage of some `MutableObjectModelBinderTest` cases
- remove unused `using`s
- part II of II for #2445
- `FormCollectionModelBinder` is an exception because container is not user-provided
- no `ModelState` entry added
- enable tests that #2445 was blocking
- fix these and other tests expecting different `ModelState` entries
- simplify logic in `FormFileModelBinder`
`ValueProviderResult`
- remove `protected` setters and parameterless constructor
- no scenario for their use in subclasses; however `ConvertTo()` remains `virtual`
- add single-parameter constructor
- use in most of the greedy and type-matching model binders
- add doc comments throughout class
nits:
- use new `ValueProviderResult` constructor in many existing tests
- `""` -> `string.Empty` and `vpr` -> `valueProviderResult` in `ValueProviderResultTest`
- improve some test names in `BodyValidationIntegrationTests`
- do not check `Message` of a Json.NET `Exception`
- 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
- #1485, #1487
- handle `TemplateInfo.HtmlFieldPrefix` in `ViewDataEvaluator.Eval()`
- attempt lookup in the `ViewDataDictionary` using full name then evaluate
relative `expression` against `viewData.Model`
- handle `null` or empty `expression` special case in this method (remove `throw`s)
- always pass relative `expression` name into `Eval()`
- remove `null` or empty `expression` handling from higher-level code
- in a couple of cases, special-case returned `ViewDataInfo`
- #2662
- remove incorrect guard from `DefaultHtmlGenerator.GenerateRadioButtion()`
- add doc comments for the core methods that have changed
- enable unit tests skipped due to one of above bugs
- fix one (yeah, just one) other test with incorrect expectations
- remove functional test comments about the above bugs and update expectations
nits:
- move some comments describing `ViewDataEvaluator` methods above the methods