Reproducing a bug

Create new ASP.Net MVC application:

image

Create an action that take non nullable argument called 'id':

[HandleError]
public class HomeController : Controller
{
    public ActionResult Index()
    {
        ViewData["Title"] = "Home Page";
        ViewData["Message"] = "Welcome to ASP.NET MVC!";

        return View();
    }

    public ActionResult Test(int id)
    {
        return Content(id.ToString());
    }

    public ActionResult About()
    {
        ViewData["Title"] = "About Page";

        return View();
    }
}

Go to home/index.aspx and add the following before the final </asp:Content> tag:

    <% using(Html.BeginForm("Test","Home")){ %>
        <%=Html.Hidden("id",2) %>
        <input type="submit" value="test" />
    <%} %>

Visit the site and see that you indeed have a test button on the page. Click the button.

Get an exception:

image

I am going to assume this is a bug.

This is on the ASP.Net MVC beta bits.

Print | posted on Friday, November 07, 2008 6:29 PM

Feedback


Gravatar

# re: Reproducing a bug 11/7/2008 6:50 PM Rob

Submit to codeplex?


Gravatar

# re: Reproducing a bug 11/7/2008 7:03 PM Simone

I guess this is related to your previous post: in this case the action invoker takes the parameter that comes from the url parameter list, which should be (if u are using the default routes) and empty string. So it cannot find an valid int for the Test action.
Well... at least it's my guess without doing more tests... try removing the "id" parameter from the route and see what happens


Gravatar

# re: Reproducing a bug 11/7/2008 7:10 PM Stephen

I think this is purely because the routing isn't looking into form values to resolve parameters.. generally routing is resolved from url defined parameters or query string values.


Gravatar

# re: Reproducing a bug 11/7/2008 7:23 PM Simone

@Stephen: the route must look only in the url... it's the action invoker that should probably be smarter to detect which id (the default one retrieved by the url parameter or the one that comes from the HttpRequest) is the right one


Gravatar

# re: Reproducing a bug 11/7/2008 7:23 PM Stephen

Actually your issue on codeplex explains this more, for whatever reason, the routing obviously isn't looking at the default values last: one would think:

url parameters,
qs parameters,
form parameters,
default parameter (if its convertable)


Gravatar

# re: Reproducing a bug 11/7/2008 8:55 PM Haacked

Thanks! This is a much better bug report than your last one. ;) I confirmed this behavior and it definitely doesn't seem right. I'll circle back with my dev/QA team and figure it out. Thanks!


Gravatar

# re: Reproducing a bug 11/7/2008 9:03 PM Haacked

Ok, it turns out this is by design right now. By convention, if you have a parameter name defined in your route with a default *and* you specify a parameter name to an action method with the same name, we assume you want us to populate that with the route value.

The easy fix is to change your default route from id to something else (routeID for example) so that there's no conflict. Otherwise the id in your action method has two meanings.


Gravatar

# re: Reproducing a bug 11/7/2008 9:27 PM Ayende Rahien

The first one wasn't a bug report :-)

I would say that this is a wrong by design choice to make.
Especially when it took me a really long while to figure out what was going on.
The route doesn't have an ID parameter, so it should fall back to looking at the request params.
Only if it can't find anything, should it try to use the default.

As you noted yourself, this doesn't look right. It also mean that something that I do in one place can adversely and non obviously affect in a completely different place.


Gravatar

# re: Reproducing a bug 11/7/2008 9:37 PM LeviB

Ayende - The team noticed that you opened a bug report on CodePlex <www.codeplex.com/.../View.aspx?WorkItemId=2549> regarding this issue. I commented on your feedback there to explain the subtleties of the situation a bit more. Thanks for the feedback. :)


Gravatar

# re: Reproducing a bug 11/7/2008 9:41 PM Haacked

Agreed, we'll take a look at it in our next triage meeting. I mentioned it's currently by design, but we will re-evaluate the design.


Gravatar

# re: Reproducing a bug 11/7/2008 11:45 PM Joe

@Phil,

See my comment in Ayende's previous post. I could have sworn this wasn't the way it worked before. In the initial releases if the route didn't have a default value, but it was supplied in the query string then it would take that. Also renaming the parameter isn't always an option.


Gravatar

# re: Reproducing a bug 11/8/2008 9:15 AM Ben Scheirman

I have seen this behavior in past previews as well. I usually get around it by changing my form values to not conflict with route values, but that get's aggravating after a while.


Gravatar

# re: Reproducing a bug 11/10/2008 1:28 AM Andrew Hallock

Just curious as to why the ID is a hidden input value rather than a parameter in the URL. I started putting IDs in hidden inputs, but soon realized they really belong in the form's action attribute as part of the action path, since that's how you originally came to the resource.

Example:

GET:
/employee/123/edit

POST:
/employee/123/do-edit

Title  
Name  
Email
Url
Comments   
Please add 7 and 8 and type the answer here: