- add `IHtmlGenerator.GetCurrentValues()` method
- bring together bits of `GenerateSelect()` and `UpdateSelectListItemsWithDefaultValue()`
- get rid of ugly `out` parameter
- also allows `<option/>` tag helpers to run before `<select/>` helper generation
- match `null` values and `SelectListItem`s with empty values
- match `enum` names correctly
- add doc comments for `IHtmlGenerator.GenerateSelect()` methods
This change removes reflection from validator providers, and instead
relies on cached metadata in in the modelmetadata.
In general this means that our MVPs don't need to cache anything, they
just look at the metadata and create what they need.
In the case of data-annotations, we update the model details provider to
add validation attributes to the modelmetadata. This would allow someone
to replace the DataAnnotationsValidatorProvider, but still use the
metadata in these attributes.
The change to the IModelValidatorProvider api (to use a context) is
intended to minimize allocations. Currently each validator provider needs
to return a list so you end up with N+1 lists (N validators + a final list
to compine them all). This change will let us just create the final list
(and a small context object). This is a very very high traffic API so it
seemed worth doing.
There's also some general massaging of namespaces and file locations.
- use named parameters more often
- add more comments about returned `ModelBindingResult`
- clean up `ModelBindingResult` doc comments
- cleanup `using`s
Nits:
- cleanup trailing whitespace
- change `retVal` -> `result` in `KeyValuePairModelBinderTest`
Separates the MMP into two phases:
1). Creation of the ModelMetadata, discovery of properties and attributes
(reflection) is part of the MMP
2). Lookup of details based on attributes is now part of another phase,
and has its results cached.
Users can now implements and register an IFooMetadataProvider to customize
a single aspect of metadata (see how data annotations does it).
- #1468
- Always use `ModelExplorer` in `<select/>`, `DropDownListFor()` and `ListBoxFor()` cases
- allows evaluation of more-complex expressions
- Use `ViewData.Model` in `DropDownList()` and `ListBox()` template cases
- `ViewData` was previously ignored in these cases
nit: change `ViewDataDictionary.Eval()` to return `Model` if `expression` is `null` or empty
- now `throw` on `null` or empty `expression` name in `ViewDataEvaluator.Eval()`
- simplifies some of the higher-level code
- no change to `selectList` fallback; `Model` incorrect for that case
- no change to `GenerateRadioButton()`; would change behaviour unrelated to #1468
- this helper uses incorrect `ViewData` lookup text, see #1487
- see commit 9d5364c
- never correct to pass a `Func<object>` to `GetExplorerForExpression()`
- `<label/>` tests succeeded because that tag helper doesn't use expression result
- `<select/>` tests succeeded because that tag helper gets result from `ViewData`
- does not use `ModelExplorer` due to #1468
nit: update variable names `metadata` -> `modelExplorer`
N. Taylor Mullen
Doug Bunting
Kirthi Krishnamraju
Kevin Dockx
Harsh Gupta
ianhong
Ryan Nowak
Ajay Bhargav Baaskaran
Hao Kung
Kiran Challa
Praburaj
Brennan
sornaks
Levi B
Kiran Challa
Yishai Galatzer