For each of these TODOs:
- If there's an active bug tracking the work, and the TODO provides
something of value, I left it and standardized the formatting. I also
added comments to the bug.
- If the comment provided no value (implement feature X when we do feature
X), I deleted it with impunity.
- If the comment was stale (won't fix or just out of date), then we
removed it uncerimoniously.
There was a single TODO that was actually actionable, so I enabled that
test.
- TagHelperAttributeDescriptors changed to be lighterweight and not depend on PropertyInfo, had to modify our use of them to work with the new contract.
- scenarios where helper takes different code paths were not well-explored
nits:
- improve a few comments and names
- refactor some setup code into helper methods
- use `EmptyModelMetadataProvider`, not `DataAnnotationsModelMetadataProvider`
Test gap around `GenerateTextBox()`'s `format` argument is temporary.
- #1523
- remove `TagHelperOutput.Merge()` extension method entirely
- test tag name preservation with all MVC tag helpers
- `<input/>` tag helper generation of a checkbox wasn't previously tested
nits:
- fix argument order in a couple of `Assert.Equal()` calls
- remove use of "original tag name"
This change enables some compatibility scenarios with MVC 5 by expanding
the set of legal ways to configure attribute routing. Most promiently, the
following example is now legal:
[HttpPost]
[Route("Products")]
public void MyAction() { }
This will define a single action that accepts POST on route "Products".
See the comments in #1194 for a more detailed description of what changed
with more examples.
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
Ryan Nowak
Pranav K
N. Taylor Mullen
Doug Bunting
Ajay Bhargav Baaskaran
ianhong
kanchanm
Kiran Challa
Harsh Gupta
SonjaKhan