This is a major change to how we handle the scenario where a controller is
a filter. We want to change the lifetime of the controller object, by
scoping it around action filters and result filters. This means that a
controller class can only implement action filters and result filters.
To implement #384 - we're creating a delegating filter class
'ControllerFilter' which will forward calls to the implementation of the
controller. This is discovered in the controller model and added to the
filter collection. This filter is removable as an opt-out of this feature.
The ControllerFilter only implements action filter and result filter, so
the new restriction about filter types on Controller is in place. A future
change will move the instantiation of the controller to after resource
filters.
This is a major change to how we handle the scenario where a controller is
a filter. We want to change the lifetime of the controller object, by
scoping it around action filters and result filters. This means that a
controller class can only implement action filters and result filters.
To implement #384 - we're creating a delegating filter class
'ControllerFilter' which will forward calls to the implementation of the
controller. This is discovered in the controller model and added to the
filter collection. This filter is removable as an opt-out of this feature.
The ControllerFilter only implements action filter and result filter, so
the new restriction about filter types on Controller is in place. A future
change will move the instantiation of the controller to after resource
filters.
This change adds support for our three-valued logic to the default value
handling part of the MutableObjectModelBinder.
The issue is that we want to look up a default value when a 'greedy' model
binder returns true but doesn't find a value.
We also don't want to call the property setter unless there is:
1). A value from model binding OR
2). A default value
In general all properties are get/set so filters can change them.
- some validate for not-null
- where we use services it's get/set also
Services are resolved in the Execute method if not provided.
A few more ActionResults that return a body have the ability to set a
status code now (optional).
- React to aspnet/Razor#221
- Modified existing TagHelper tests to no longer rely on ContentBehavior.
- Updated signatures of TagHelperExecutionContext and TagHelperContext pieces.
- React to aspnet/Razor#221
- Modified existing TagHelpers to no longer rely on ContentBehavior and to instead utilize GetChildContentAsync, PreContent, Content and PostContent.
- #1685
- move `ValidationSummary` type to the `Microsoft.AspNet.Mvc` namespace
- update tests and samples to match
- remove tests for case-insensitivity of `ValidationSummary` property values
- part II of #1253
- an expected case in template .cshtml files
- expression has name `""`; led to `ArgumentException` in `ModelExpression`
- test `@Model` and `@model.Property` in unit and functional tests
- update baselines to match
nits:
- remove a few unecessary `@`s in .cshtml files
- correct field names & ids in ProductList.cshtml (`foreach` confuses MVC)
- led to correct valiation attributes as well
- part I of #1253 using new Razor capabilities
- update baselines to match latest code generation
- use new `CodeBuilderContext` and `TagHelperAttributeValueCodeRenderer` signatures
- test complex expressions in bound non-string attribute values
See #1695 for a detailed explanation. This change builds support into the
system for the case that a model binder returns true without setting a
value for the Model.
In this case, validation will be skipped if it's a top-level object.
Note that explicitly setting null will still run validation.
This is a demonstration of how to inject an IRouter in between traditional
routes and MVC's handler. This allows you to accomplish a variety of
things that were possible with WebAPIs handlers, but inside the routing
system.
The example here turns a header representing the user into a locale, which
is used to select a controller. You could do other things like reject the
route match or change link generation.
There is one subtle project change here, to allow the same to be possible
for attribute routing, we need to create the attribute route after running
the user's routing configuration code.
- Support for binding posted file to type IFormFile
- Support for multipart/form-data in FormValueProviderFactory
- Updated Mvc Sample
- Added relevant unit and functional tests
- #1766
- use `ReplaceCultureAttribute` to avoid `CultureReplacer` thread consistency checks
- also update test expectations to match new formats
nit: use `UseMiddleware()` extension method rather than `app.Use()`
1) A few `<input/>` tag helpers in a partial view invoked (`@Html.PartialAsync()`) in a loop within a `@for` inside an `using @Html.BeginForm()` block.
2) A custom template e.g. EditorTemplates/MyType.cshtml containing a mix of `<input/>`, `<select/>`, and various input HTML helpers invoked (`@Html.Editor[For]()`) in a loop within a `@for` inside an `using @Html.BeginForm()` block.
3) `<select/>` tag helpers with an `using @Html.BeginForm()` block
4) HTML helpers in the <form/> tag helper
The action invoker no longer needs access to model metadata or to the
input formatter selector. This change removes the same as constructor
parameters and cleans up tests which use the invoker.
This is a new filter stage that surrounds the existing model binding,
action, and result parts of the pipeline. Resource Filters run after
Authorization Filters.
The other major change is to support one of the primary scenarios for
Resource Filters. We want a filter to be able to modify the inputs the
model binding (formatters, model binders, value providers, etc) -- this
means that those changes need to be held on a context object and preserved
so that they can be used in the controller.
So, IActionBindingContextProvider is removed - the ActionBindingContext
will be created by the invoker. For now it will be part of the action
context.