- with some `<text>` hacks, generated HTML is almost identical to tag helper version
- attribute order (HTML helpers consistently order alphabetically) is primary difference
- bit more testing, therefore related to #453
nits:
- remove some trailing whitespace
- clean up style in `MvcTagHelperTest[s]` and `MvcTagHelper_HomeController`
- e.g. more init syntax, fewer duplicate variables
- correct "MvcTagHelperTest~~s~~" file / class name
- remove unused `Order.OrderNumber` property in MvcTagHelpersWebSite project
- correct one spelling mistake
- remove `explicitValue` variables from two `DefaultHtmlGenerator` methods
This follows up a [code review comment](https://github.com/aspnet/Mvc/pull/1834/files#r23120381)
related to `DefaultHtmlGenerator.GenerateCheckBox()`. Same issue appears in
`DefaultHtmlGenerator.GenerateRadioButton()`.
@pranavkm -
> Also a different variable name? There's a parameter isExplicitValue that
> follows which always has a false value. Reusing this name seems messy.
My response to that comment should not be repeated. @pranavkm was correct
that the only issue here is naming. `explicitValue` was too easily
confused with the `isExplicitValue` argument used a few lines later.
They had separate purposes: `explicitValue` related to the "checked"
attribute while `isExplicitValue` relates to the "value" attribute.
- Made @inject handle trailing semicolons identical to @using; essentially ignores it.
- Added parser, runtime/designtime codegen and functional tests.
- Added Microsoft.AspNet.Mvc.Common.Test.
- Transitioned pre-existing Microsoft.AspNet.Mvc.Common tests to the new test project.
- Updated transitioned tests to also work in CoreCLR (except ones with moq).
#1857
This change makes ApiDescription and ApiParameterDescription aware of all
of the new features we built into model binding for enhanced DTO support
(uber-binding).
The main change is that instead of sticking just to the declared
parameters on the action itself, we now traverse model metadata and break
the parameters down based on their logical data source.
This means that a model like the below will yield 3 parameters:
public class ProductChangeCommandDTO
{
public int Id { get; set; }
[FromBody]
public ProductDetails Changes { get; set; }
[FromQuery]
public string AdminComments { get; set; }
[FromServices]
public IProductRepository Repository { get; set; }
}
The 'Repository' will be hidden, as it's not related to user input.
Additionally, we treat different sources differently. In the
above example, 'Changes' is from the body and will be treated as a
leaf-node.
However if you use nested DTOs that are bound from the query string (using
[FromQuery]) or similar, we'll recursively explore to find as much
structure as possible.
This information is combined with data from the route template to give a
much more complete picture than we ever could in the past for parameters,
especially when DTO/Command pattern is used.
- add a couple more exclusions to .gitignore (recent VS additions)
- remove `<ProjectExtensions/>` elements
- update files that don't have the correct output directories
- remove dangling PrecompilationWebSite.kproj file