This doesn't go through the Razor tag helper discovery pipeline because
this can really only ever work for ITagHelper based taghelpers. So
there's really no point in reusing that logic, which would be hard
anyway.
- Prior to this change using asp-page-handler on its own did not create correct `<form>` elements. There were multiple issues, one as that the `FormTagHelper` would purposefully drop into a no-op code path. Second is the `DefaultHtmlGenerator` didn't call through to the `UrlHelper` correctly.
- Added functional test cases to validate asp-page-handler can live on its own on a form tag. This also included adding a variant where method="post".
- Added a `FormTagHelper` unit test to validate the `PageHandler` property is consumed properly.
#6208
- Added functional test to verify `asp-*` attributes on form taghelpers work as expected.
- Added a unit test to validate `FormTagHelper` behaves as expected.
- Moved `Method == "get"` checks into appropriate code paths. These include the one where a user specifies an empty or non-existent `action` attribute and where a user doesn't utilize any `asp-*` attributes. In the later, we default `Method` to `"get"` if it's not provided.
#6006
- Added a test case to the HtmlGeneration functional test (the one verifying complex FormTagHelpers).
- Added unit test verifying antiforgery behavior when it's the only provided parameter.
#6006
- Added functional test to validate that non-attributed form tags have an antiforgery input generated. Re-generated baseline to reflect changes.
- Added a unit test to validate that parameterless `FormTagHelper`s behave as expected.
#6006
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.