- use the request's Path and QueryString rather than default Action() return
value
- actual special case detects all parameter values match the defaults
- this slightly expands the scenarios where the query string is added but
removes an odd inconsistency between `html.BeginForm()` and (say)
`html.BeginForm(FormMethod.Post)`
Fixes#278
DataAnnotations used to reference System.Reflection.Compatibility, which
was giving us a reference to some methods "for free". Really we should
have been pulling in this package all along.
- copy from legacy MVC
- get `ListBox[For]()` methods in correct places and working
- also usual stuff: `var`, `[NotNull]`, remove `IDictionary<,>` overloads
- `ListBoxHelper()` -> `GenerateListBox`
- already had all the bits needed in `GenerateSelect()`
- special-case `null` or empty `name` in GenerateSelect()
- ensure `ArgumentException` has correct parameter name
- lower-level problem affected `CheckBox()` as well
- use `ListBox()` and `ListBoxFor()` in MVC sample
- use `ListBox()` in an editor template
If the controller implements IFilter, it will be added to the filters
collection.
It's hardcoded to be 'first' as it was in MVC, but can be overridden by
implementing IOrderedFilter.
These were accidentally the same names as the action filter methods.
Oopsies. Name taken from MVC and appended Async for the async version
because that's how we roll.
- a single test is failing under CoreCLR only
- using the resource-related properties of a `ValidationAttribute` in
precisely one place – the failing test.
- in .NET the DataAnnotations assembly is somehow able to get access to
`internal` resources
- that doesn’t work under CoreCLR
- short-term fix is to add an `[InternalsVisibleTo]` in the test
assembly, giving DataAnnotations access to the resource
Will also file a bug in the DataAnnotations repo
dougbu
David Fowler
Andrew Peters
Eilon Lipton
Yishai Galatzer
Wei Wang
Pranav K
Ryan Nowak
lajones
sornaks
harshgMSFT
Chris Ross
Sebastien Ros
Louis DeJardin
N. Taylor Mullen
Hao Kung