Skip to content
This repository was archived by the owner on Nov 27, 2018. It is now read-only.

Make ambient values part of 'accepted values' during the constraints part of link generation. #77

Closed
rynowak opened this issue Jul 2, 2014 · 2 comments

Comments

@rynowak
Copy link
Member

rynowak commented Jul 2, 2014

We accidentally changed this behavior from old MVC. This lets us do some pretty useful stuff with constraints so we should bring it back.

Here's an example (old MVC):

routes.MapRoute(
                name: "Default_slug",
                url: "slug/{controller}/{action}",
                defaults: new { controller = "Home", action = "Index", foo = "bar" },
                constraints: new { foo = new MyConstraint() });

routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}}",
                defaults: new { controller = "Home", action = "Index" },
                constraints: new { foo = new MyConstraint() });

If you navigate to / then the second route will match, and produces the ambient values:
{ controller = "Home", action = "Index" }.

Then inside that action, generate a link to another action Url.Action("About").

The inputs to link generation:
values: { action = "About" }
ambient values: { controller = "Home", action = "Index" }

When constraints are called, they see the 'accepted values:
{ controller = "Home", action = "About" }

Note that the value foo = "bar" is not present, even when running the first route's constraints.

Now repeat, but navigate to /slug to match the first route, producing the ambient values:
{ controller = "Home", action = "Index", foo = "bar" }.

Generate the same link:
values: { action = "About" }
ambient values: { controller = "Home", action = "Index", foo = "bar" }

When constraints are called, they see the 'accepted values:
{ controller = "Home", action = "About", foo = "bar" }

Note that foo = "bar" is present because it's an ambient value and not because it's a default value of the route.

@rynowak rynowak added the bug label Jul 2, 2014
@rynowak
Copy link
Member Author

rynowak commented Jul 2, 2014

@Eilon - confirmed the the behavior we want is the same as legacy

rynowak added a commit that referenced this issue Jul 2, 2014
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.
rynowak added a commit that referenced this issue Jul 8, 2014
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.
@rynowak
Copy link
Member Author

rynowak commented Jul 11, 2014

Fixed in: 63dcdd6

@rynowak rynowak closed this as completed Jul 11, 2014
@danroth27 danroth27 added this to the 1.0.0-alpha3 milestone Aug 17, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants