The properties on TemplateRoute for DataTokens and Defaults are now
readonly. This prevents modifying these collections in a way that
invalidates cached data, or violates thread-safety.
To do the same for constraints, this change includes a substantial refactor
of how we realize inline constraints, and moves the constraint resolver
out of the parsing phase.
This allow creates a builder for the constraint map, that will make it
easier to implement features like optional constraints, and is reusable
for anyone building their own type of routing system.
This is the routing part of the fix. MVC will be updated as well
(attribute routing).
As the graph of routers is traversed, routers add themselves to the
current 'path', which unwinds on a failed path.
This mechanism is opt-in. Whoever adds something needs to remove it as
part of cleanup. If a router in the tree doesn't interact with the
.Routers property, then there are no consequences for those that do.
Additionally, fixing #116 as part of the same change. This means that we
create a nested 'RouteData' and then restore it on the way out. This is
simpler than just dealing with the .Routers property in isolation.
Changed the implementation of route template to merge the existing route data
with the values obtained from parsing the request path with the given template.
Restored original route data values in case the route template data does not match.
This change makes RouteValueDictionary a full IDictionary implementation
instead of a subclass of Dictionary.
Followed the patterns used in the old implementation, namely preserving
the struct-returning behavior of Keys/Values/GetEnumerator.
This is useful for a variety of interesting scenarios in link generation
where a default value doesn't appear in the route template as a parameter.
This can be used to implement the desired behavior for areas - where the
'area' key is sticky.
This change adds tests and makes the behavior consistent with legacy MVC
as far as what values are visible in constraints.
This is important because it allows constraints to make decisions based on
whether or not a value is present even if it's not in the template. This
is similar to the behavior of WebAPI link generation or Area link
generation in MVC 5 - but without hardcoding.
This is the routing part of these changes, and just the breaking changes
parts.
Follow-ups will add:
- DataTokens
- Tracking the logical stack of routers
Moving out Default Handler and IInlineConstraintResolver from RouteCollection.
These are moved to a new interface IRouteBuilder, (instead of an IInlineConstraintResolver, it takes in an IServiceProvider).
This means all RouteCollectionExtensions are moved to RouteBuilderExtensions.