This change moves controller creation to the stage immediately before
model binding. The controller will be disposed/released before Resource
Filters run their 'OnResourceExecuted' method. Previously the controller's
lifetime surrounded all filter invocation.
Additionally, the Controller property is now gone from ActionContext, and
is moved to the 4 filter contexts that should have access to it
Action*Context and Result*Context.
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).
1. Template parser now allows a parameter to be an optional parameter in a complex segment if
it is the last and only optional parameter and it is followed by a period.
2. Template matcher modified to take into consideration the optional parameter in the complex
segment. Also the period shouldn't be present if the optional parameter is not present
- 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
- Modified the CSharpTagHelperCodeRenderer to understand a single line of TagHelper rendering (instead of doing different things based on ContentBehavior).
- Modified existing CodeGen output to reflect new content changes.
#221
Pranav K
Kirthi Krishnamraju
Ajay Bhargav Baaskaran
David Fowler
Stephen Halter
Praburaj
Suhas Joshi
Hao Kung
Ryan Nowak
Doug Bunting
Mugdha Kulkarni
N. Taylor Mullen
Youngjune Hong
tushar gupta
Harsh Gupta
AndriySvyryd
Yishai Galatzer