The change here is to always use the provided formatter, instead of using
it as a fallback. This is much less surprising for users.
There are some other subtle changes here and cleanup of the tests, as well
as documentation additions.
The primary change is that we still want to run 'select' on a formatter
even if it's the only one. This allows us to choose a content type based
on the accept header.
In the case of a user-provided formatter, we'll try to honor the best
possible combination of Accept and specified ContentTypes (specified
ContentTypes win if there's a conflict). If nothing works, we'll still run
the user-provided formatter and let it decide what to do.
In the case of the default (formatters from options) we do conneg, and if
there's a conflict, fall back to a global (from services)
JsonOutputFormatter - we let it decide what to do.
This should leave us with a defined and tested behavior for all cases.
- ensure `ViewDataDictionary` constructors are not passed a `null` or
`Mock.Of<IModelMetadataProvider>()` instance
- `ViewDataDictionary` constructors always use the `IModelMetadataProvider`
- `viewData.ModelMetadata` now never `null`
- `ViewDataDictionary<int>.Model` no longer throws if read before it's written
- `ViewDataDictionary.ModelMetadata` now copied to new instances in fewer cases
- e.g. don't use unusual `object` datatype with customized `ModelMetadata`
This change adds the concept of a full-name to viewcomponents. View
components can be invoked using either the short name or long name. If the
provided string contains a '.' character, then it will be compared against
full names, otherwise it will be matched against short names only.
The short name is used for view lookups.
If the name is explicitly set via ViewComponent attribute, then the full
name is the name provided. The short name is the portion of the name after
the last '.'. If there are no dots, then the short name and full name are
the same.
If the name is not set explicitly, then it is inferred from the Type and
namespace name. The short name is the Type name, minus the 'ViewComponent'
suffix (if present). The full name is the namespace of the defining class,
plus the short name.
Taking the suggestion here to move these to a sub-object. This is future
proof in the event that we need to capture more data for ApiExplorer, and
reads better.
ViewComponents and Controllers now follow the same rules exactly for what
types of classes they can be.
Also corrected a bug in a test for controllers. Closed-generic types can
be controllers, the test was wrong.
- Cleaned up some existing bad code that worked around case sensitive TagHelperOutput.Attributes.
- Modified MergeAttributes to be case insensitive when it comes to merging class attributes.
- Added a test to verify the new MergeAttribute case insensitive class merging.
aspnet/Razor#186
- This involved adding the StringComparer.OrdinalIgnoreCase comparer to the TagBuilder's Attributes dictionary.
- Added tests to validate that all methods that made use of TagBuilder.Attributes abide by the new ignore case mechanic.
- Added two sets of tests to validate the new functionality of Object => Dictionary HTML helper tests.
- Modified a functional test that utilizes HTML Helpers to provide same attribute-different case objects.
- Fixed existing HTML helper tests to account for new ordering of attrbutes (dictionary no longer adds key value pairs, it sets them).
#1328
This also comes with a rename of the namespace
Microsoft.AspNet.Mvc.ApplicationModel to
Microsoft.AspNet.Mvc.ApplicationModels.
Also tuned up some parameter and variable names for increased
understandability.
This change modifies the default parameter binding behavior for an
ApiController to use the WebAPI rules.
'simple types' default to use route data or query string
'complex types' default to use the body (formatters)
Adds ModelBindingAttribute to enabled model binding
- #704 part 2 of 2
- change `@Html.Id()` to sanitize return value; was identical to `@Html.Name()`
Copied `TagBuilder.CreateSanitizedId()` and `TagBuilder.Html401IdUtil` from MVC 5.2
- except this `CreateSanitizedId()` returns a valid identifier if first `char` is not a letter
- e.g. "[0].Name"
nits:
- expand variable names, use lots of `var`, put `public` members first
- add doc comments for `CreateSanitizedId()`
Note users will be able to apply different sanitization once we fix#1188.
- also make `TagHelperOutputExtensions.MergeAttributes()` case-insensitive
nits:
- deliniate attribute names in all resource strings
- update validation messages in TagHelperSample.Web
- Changed TagHelper property accessors from private to protected internal.
- Changed throw tests to be shorter.
- Changed reflection setting to now use the internal accessibility of the TagHelpers
- Removed activator to just use internal accessibility of TagHelpers.
- Changed new StringWriter() instances where we didn't need the StringWriter to be TextWriter.Null
- Added a TagHelper that targets the <a> tag and allows users to do the equivalent of Html.ActionLink or Html.RouteLink.
- Added tests to validate AnchorTagHelper functionality.
#1247
- Added the FormTagHelper.
- Utilized the IHtmlGenerator to share base functionality with the HTMLHelper counterparts.
- Added tests to validate FormTagHelper functionality.
#1246
- make a few more methods available as `internal static` in `DefaultHtmlGenerator`
- remove `IHtmlGenerator.GenerateOption()`; now `internal static`
nits:
- add `IHtmlGenerator.IdAttributeDotReplacement`
- move `DefaultHtmlGenerator.IdAttributeDotReplacement` after constructor
- move `HtmlHelper.ActionLink()` below static methods
- move newly-`internal` methods together in `DefaultHtmlGenerator`
- correct placement of `DefaultHtmlGenerator.GetValidationAttributes()` comment
- new Microsoft.AspNet.Mvc.TagHelpers.Test project
- bit of test infrastructure -- `TestableHtmlGenerator`
- short-curcuits validation attribute and AntiForgery additions
- should help when testing all MVC tag helpers
Ryan Nowak
sornaks
Pranav K
Doug Bunting
jacalvar
N. Taylor Mullen
Harsh Gupta