These tests verify that per-request services can be injected into assets
that users provide/implements (filters, constraints, controllers, views,
etc).
The purpose is to verify that the services are correctly resolved from the
per-request service container, and don't have state that lingers and
influences the next request. This is important because changing the
lifetime of a framework services could easily impact the lifetimes of
others, and ultimately of something the user created.
Rather than throwing here, this does what routing does. If request
services aren't set, we just create our own scope.
This will NOT create an extra scope if request services are already set.
- clean up "the the" in XML comments
- simplify refactoring VS did when I renamed `GetHtmlHelperForViewData()`
- fix existing issue in `HtmlHelperCheckboxTest.CheckBoxReplacesUnderscoresInHtmlAttributesWithDashes()`
(was using a `HtmlHelper<ViewDataDictionary<TestModel>>`)
- add missing license headers
- make "post" more obvious
- use `Assert.IsAssignableFrom()`
nit: remove unused `using`s in `HtmlHelperLinkGenerationTest`
- helps w/ #453 since `Html.BeginForm()` wasn't previously tested
- provide a `DefaultTemplatesUtilities.GetHtmlHelper()` overload with an
`IHtmlGenerator` parameter
- update `DefaultTemplateUtilities` to use `DefaultHttpContext`
- stop using a mock for this purpose; provides a non-`null` `Request`
nit:
- `DefaultTemplatesUtilities.GetHtmlHelperForViewData()` -> `...GetHtmlHelper()`
for consistency with other overloads
This is the MVC companion to https://github.com/aspnet/Routing/pull/122
As routing flows, routes replace the route data and mutate a copy. This
allows users to make changes that dirty the data without affecting
undesired state changes.
We also add the 'next' router for diagnostic purposes.
- value may remain in the `FormContext` beyond `</select>` end tag but will
be cleaned up at the `</form>` end tag of the containing `<form/>` element
- `SelectTagHelper` called prior to helpers for contained `<option/>`s and
not again later
- adjust mock setups to handle new `GenerateSelect()` call
- add assertions for expected `FormContext.FormData` entry
nit: mention #1468 in a test comment
- use new `ModelMetadata.HtmlEncode` property in HTML helpers
- specifically in default HTML display and editor object templates (e.g.
`@Html.DisplayFor()`) when value is non-`null` and the template is invoked
with template depth greater than 1
- similar to MVC 5.2 commit [2b12791aee4f](https://aspnetwebstack.codeplex.com/SourceControl/changeset/2b12791aee4ffc56c7928b623bb45ee425813021)
nits:
- remove dupe `null` check in `DefaultDisplayTemplates.ObjectTemplate()`
- move backing fields initialized with constants together in `ModelMetadata`
The change here is to always use the provided formatter, instead of using
it as a fallback. This is much less surprising for users.
There are some other subtle changes here and cleanup of the tests, as well
as documentation additions.
The primary change is that we still want to run 'select' on a formatter
even if it's the only one. This allows us to choose a content type based
on the accept header.
In the case of a user-provided formatter, we'll try to honor the best
possible combination of Accept and specified ContentTypes (specified
ContentTypes win if there's a conflict). If nothing works, we'll still run
the user-provided formatter and let it decide what to do.
In the case of the default (formatters from options) we do conneg, and if
there's a conflict, fall back to a global (from services)
JsonOutputFormatter - we let it decide what to do.
This should leave us with a defined and tested behavior for all cases.
- ensure `ViewDataDictionary` constructors are not passed a `null` or
`Mock.Of<IModelMetadataProvider>()` instance
- `ViewDataDictionary` constructors always use the `IModelMetadataProvider`
- `viewData.ModelMetadata` now never `null`
- `ViewDataDictionary<int>.Model` no longer throws if read before it's written
- `ViewDataDictionary.ModelMetadata` now copied to new instances in fewer cases
- e.g. don't use unusual `object` datatype with customized `ModelMetadata`
- `null` checks can generally be removed but in one case needed to
special-case metadata for `object`
nit: remove duplicate empty `string` check in
`ExpressionMetadataProvider.FromStringExpression()`
ianhong
Ryan Nowak
Pranav K
Doug Bunting
kanchanm
Ajay Bhargav Baaskaran
Kiran Challa
N. Taylor Mullen
Harsh Gupta
SonjaKhan
sornaks