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).
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.
- StyleCop working again (handles C# 6.0 additions) though only locally for me
- disable some new rules:
- ConstFieldNamesMustBeginWithUpperCaseLetter
- InstanceReadonlyElementsMustAppearBeforeInstanceNonReadonlyElements
- StaticReadonlyElementsMustAppearBeforeStaticNonReadonlyElements
- StaticReadonlyFieldsMustBeginWithUpperCaseLetter
- PrefixCallsCorrectly
- correct remaining violations
- lots of long lines for example
- use more `var`; some manual updates since StyleCop doesn't check seemingly-unused blocks
nit: remove new trailing whitespace (was paranoid about adding it w/ fixes)
The ParameterModel and ParameterDescriptor have had a notion of
optionality for a while now, even though all parameters are treated as
'optional' in MVC.
This change removes these settings. Optionality for overloading in webapi
compat shim is reimplemented via a new binder metadata.
This change adds an interface for the functionality provide by
RouteConstraintAttribute, and adds support for configuration constraints
on actions/action-model.
Fix - When the model is passed in to a View, ViewDataDictionary sets it. During this process, we recurse through all the properties and create FastPropertyGetters for each of them. In this case, since it is an enumerable, the properties which we recurse through are not the elements of the collection but the properties of the Enumerable instead. i.e - Enumerable.Current. Creating getters for these properties are not necessary. The fix moves the property iteration step to a place where the properties are actually requested.
- Splitting TypeInformation class into two and separating their caches appropriately.
1. Updated ViewComponent to exposes similar properties to the existing ones in controller where
appropiate. We've left out Resolver for being a bad pattern (just inject the dependency on the constructor
or use Context.RequestServices to access it if needed) and Response as although available through the Context
property, it shouldn't be used/modified in a ViewComponent.
2. Updated ViewViewComponentResult to follow a similar pattern as ViewResult where the constructor is
parameterless and elements like ViewEngine are resolved during execution if the user does not set the
associated property on the object.
3. Updated ExecuteAsync in JsonViewComponentResult to remove the unnecessary pragma and async keyword from the
signature and to use Task.FromResult(true) instead.
4. Cleaned up ViewViewComponentResult tests.
- #EngineeringDay
- license present but incorrect in just a few files
- skip generated files such as Resources.Designer.cs and files under
test\Microsoft.AspNet.Mvc.Razor.Host.Test\TestFiles\Output
- #EngineeringDay
- VS does not yet format auto-properties nicely; reverted what it did
Also revert changes under
- test/Microsoft.AspNet.Mvc.Razor.Host.Test/TestFiles
- #EngineeringDay
- Total replaced: 660 Matching files: 270 in *.cs
- Total replaced: 250 Matching files: 32 in all other files
- Total replaced: 22 Matching files: 8 in a few stragglers
Did not change files under following directories
- test\Microsoft.AspNet.Mvc.Razor.Host.Test\TestFiles\Output
- test\Microsoft.AspNet.Mvc.FunctionalTests\compiler\resources
- test\WebSites\TagHelpersWebSite
(Razor generates trailing whitespace in a case or two)
Ryan Nowak
Kirthi Krishnamraju
Doug Bunting
Youngjune Hong
Harsh Gupta
Ajay Bhargav Baaskaran
Yishai Galatzer
Hao Kung
sornaks
Kiran Challa
Chris Ross
SonjaKhan
Pranav K
ianhong
Mugdha Kulkarni
Victor Hurdugaci