- #439 (3 of 3)
- extended the Validation web site to include use of `[Remote]`
- also confirm operation of the validation actions (which all reject their input)
- #439 (2 of 3)
- correct namespaces
- correct `Resources` class and member names; add new resources
- add `RequestServices` property to `ClientModelValidationContext`
- adjust to modern `IUrlHelper` API
- add `IClientModelValidator` support in `DataAnnotationsModelValidator`
- move previously-unused `StringSplit()` to `RemoteAttribute` and rename
- rewrite `RemoteAttributeTest`
- improve test method names
Reduce number of `[Remote]` constructor overloads
- remove `AreaReference` enum and related `[Remote]` constructor overload
- use `null` or empty `string` as explicit reference to the root area
- generally reduce parameter validation; match `UrlHelper`
Cleanup
- correct Engineering Guidelines violations
- especially: add doc comments
- correct spelling error in `_additonalFieldsSplit`
nits:
- minimize `null` checks in `AdditionalFields`
- make `GetClientValidationRules` `virtual`; some subclasses use `new` today
- add tests of `DataAnnotationsModelValidator.GetClientValidationRules()`
- remove `builder.ToString()` calls since it appears
https://roslyn.codeplex.com/workitem/246 has been resolved or Moq has
worked around that issue.
- #964
- compute `ModelMetadata.Order` based on `[Display]` attribute
- property affects e.g. `@Html.DisplayFor()` generation for complex objects
- also affects order of messages in validation summaries
- test new scenarios involving `ModelMetadata.Order`
- per-property `ModelMetadata` and related tests
- validation and `HtmlHelper` tests
- add `HtmlHelperValidationSummaryTest` (which touches on #453)
- update ModelBinding functional test to show use of `[Display(Order = x)]`
nits:
- move more `NullDisplayText` bits into proper slots (just above `Order`)
- add doc comments for `ComputeNullDisplayText()`
- add more assertions in tests using `ModelStateDictionary.HasReachedMaxErrors`
- remove some trailing whitespace
- avoid `Assert.True()` & `Assert.False()`; split some assertions up
- `""` -> `string.Empty` in affected test classes
- rename "DefaultEditorTemplatesTest~~s~~" class and file to follow guidelines
- rename "ModelBindingTest~~s~~" class and file to follow guidelines
FYI #1888 covers a predictable (or even just stable) order in the UI
Changes here are all focused around MaxModelErrors on
ModelStateDictionary.
MaxAllowedErrors now defaults to 200 (same as options). This means that
constructing a new ModelStateDictionary with the default constructor will
use this default. There's a new constructor for creating a
MaxAllowedErrors with a non-default value.
The ControllerActionArgumentBinder is now responsible for setting the
value from options onto ActionContext.ModelState. This results in better
layering and guarantees the option is respected if someone uses
extensibility to call model binding.
ModelStateDictionary.CanAddErrors is renamed to MaxErrorsReached. We
wanted to change the behavior of this property, but realized that it's
very useful inside the model validation code, so opted to renamed.
There's also a bunch of doc cleanup inside ModelStateDictionary to
simplify things and improve clarity.
This change allows you to set global defaults for ApiExplorer on the
ApplicationModel. Additionally, we're more lenient about configuring
ApiExplorer = on with conventional routing. If you turn on ApiExplorer at
the application level, we'll just skip over all conventionally routed
controllers instead of throwing.
This is a cleanup PR to improve the common usage of
ModelMetadata.Properties.
We found placed in code where both .Count and the ability to index by
property name would be useful. I was able to cascade this and simplify the
ModelBindingContext as well.
- 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