Previously global filters were added to the page application model with Action scope. This
would have resulted in incorrect ordering of filters during execution. We'll instead add
global filters separately with the right scope. #6579 will be used to express global filters
as part of the application model.
The RazorProject implementation used by MVC at runtime has a constructor
that takes an IFileProvider (used by tests). This causes ambiguities
when a user registers an IFileProvider in DI.
Cleaning up tests to use a mock instead of the file provider directly
This isn't a good fit with consistency with controllers. Discussed with
@DamianEdwards and we agreed to remove this for now and bring it back in
the future if there's a real need for it.
This changeset reckonciles the binding work we did for pages with
controllers.
A quick summary:
- Moves [BindProperty] to the MVC namespace (#6401)
- Makes [FromRoute] and friends behave consistently (#6402)
- Makes [BindProperty] work with controllers (untracked)
This change removes a 'pass through' IRazorPageActivator that we were
using to avoid the default one initializing the Page twice.
The fix is to add an adapter so that the IRazorPage that the RazorView has
isn't the *real* page, it's the adapter. The adapter doesn't have anything
interesting to activate :).
We're making this type internal in Razor, using a mock here is fine.
Also renamed some types with a generic name. The actual 'default'
RazorProject class lives in Razor and is internal.
The View Engine now needs to know about pages :(. This isn't ideal but the
view engine needs to know what set of search paths to use. This was
already hardcoded for controllers vs controllers + areas. It felt right to
further hardcode instead of introduce a wierd abstraction that we only
use.
Additionally pages use a view location expander to implement an ascending
directory search.
Pranav K
Ajay Bhargav Baaskaran
Ryan Nowak
N. Taylor Mullen
Ryan Brandenburg
Nate McMaster