Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beginnings of #47 #50

Merged
merged 2 commits into from
Jan 18, 2015
Merged

Beginnings of #47 #50

merged 2 commits into from
Jan 18, 2015

Conversation

AlexArchive
Copy link
Contributor

No description provided.

@@ -117,7 +117,10 @@ public RouteValueDictionary ShouldRedirectTo(MethodInfo method, RouteValueDictio
var redirectResult = (RedirectToRouteResult)ActionResult;

if (redirectResult.RouteValues["Controller"] == null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be redirectResult.RouteValues["Controller"] == null && typeof(TController) == typeof(T)?

Otherwise, if the action returned a redirect to the same controller, but you were checking for a different one then it wouldn't throw when it should.

You can probably add a test case for that if there isn't one already.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure off-hand.

I will spend some time to understand the code more deeply this afternoon and then issue another commit.

Thank you.

@AlexArchive
Copy link
Contributor Author

Yep. You were right.

I changed the implementation and added a test to represent the scenario you described.

What do you think now?

@robdmoore
Copy link
Member

Yep, that looks good :)

On 18 Jan 2015, at 5:42 am, ByteBlast [email protected] wrote:

Yep. You were right.

I changed the implementation and added a test to represent the scenario you described.

What do you think now?


Reply to this email directly or view it on GitHub.

@AlexArchive
Copy link
Contributor Author

I will merge this now but please don't deploy yet.

I think this qualifies as a breaking change, yes? I also think the implementation of #45 will be a breaking change too. I think we should minimize the MAJOR version number bump by deploying them together.

@AlexArchive
Copy link
Contributor Author

Thank you once more for all your input Rob -- I learn lots.

AlexArchive pushed a commit that referenced this pull request Jan 18, 2015
@AlexArchive AlexArchive merged commit 18774c5 into TestStack:master Jan 18, 2015
@robdmoore
Copy link
Member

Agree ex was literally just thinking the same thing. You should update nextversion.txt now though and the breaking changes file.

That way the repository reflects current reality.

On 18 Jan 2015, at 8:36 am, ByteBlast [email protected] wrote:

I will merge this now but please don't deploy yet.

I think this qualifies as a breaking change, yes? I also think the implementation of #45 will be a breaking change too. I think we should minimize the MAJOR version number bump by deploying them together.


Reply to this email directly or view it on GitHub.

@AlexArchive
Copy link
Contributor Author

Ok I will submit a pull request for that now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants