This change completely removes [Activate]. In a controller, you should
constructor injection or [FromServices] to access services.
To access context items (ActionContext, ActionBindingContext, root
ViewDataDictionary) you should use the respected attribute class.
We'd like to consider streamlining this further in the future by getting
down to a single injectable context for controllers, but for now this will
have to do.
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.
This also fixes#1503.
Currently all model binders except mutable object binder are independent of validation code. The mutable object binder which needs to do some validation ( for scenarios involving [BindRequired] and [BindNever]).
We would be going with an approach where required validaiton happens in input formatters and model binders.
This is needed as validation for value types can best be done at creation time.
Followup PRs:
Introduce support for skipping validation (and not binding) for a particular property/type etc.
services
* Added WithControllersFromServiceProvider that replaces the default
controller activator with a service based one.
* Move activation to DefaultControllerFactory
* Modify [Activate] behavior so that it no longer activates services. Use
[FromService] attribute to hydrate services
Fixes#1707
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.
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).
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)
- #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
1) Implemented FilePathResult to efficiently return files from disk.
2) Implemented FileStreamResult to return content from a stream.
3) Implemented FileContentResult to return content from a byte array.
1. Added HttpNotFound() to Controller.
2. Updated HttpStatusCodeResult to expose the StatusCode as a property.
3. Added unit tests for HttpNotFound() and for HttpStatusCodeResult.
4. Updated the MvcSample to add an action that uses HttpNotFound().
5. Brought back HttpNotFoundResult and added unit tests for it.