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 :).
Fixes#5874 - we are marking these methods virtual just in case someone
wants to customize the executors. These are in the 'public internal'
namespace but can't really be replaced because they aren't sufficiently
virtual.
The issue here is that route values used for action selection are
'global'. That means that pages need to have a 'null' route value for
'action' and controllers need to have a 'null' route value for pages. This
is the same way that areas work.
The fix is to move the 'merge' of route values up to a level where pages
and controllers can work together. Since ADPs use the russian-doll
pattern, the fix is to run this 'merge' in the controller ADP, but after
all of the ADs have been created.
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.
N. Taylor Mullen
Pranav K
Ryan Nowak
Jass Bagga
Ryan Brandenburg
Ajay Bhargav Baaskaran
Hao Kung