We have a large mvc2 project and just added an area to it. Now some of the paths in our forms are messed up. We are using Strongly Typed actionlinks and formextensions.
Please look at the following demo: http://iamwill.com/AreaExample.zip
The form on this page is incorrectly submitting to the area.
I think it's related to routing or just the way that area's are figured out when it's not specified.
<%= Html.ActionLink("Log On", "LogOn", "Account", new { area = "" }, null) %>
ActionLink() will never generate a link to a different area unless explicitly asked to. So, when within the
Cabinets area, the first ActionLink() call above is staying within the current area, hence the incorrect URLs. The second call is explicitly annotated as "I don't care which area you're currently in, I want to go back to the
root (empty string) area." The null parameter is necessary so that you're calling the correct ActionLink() overload.
Yeah- If you take a look at the form on the home page you can see that it's adding the Area to the path of the form action. The homepage is in the root area, but it's incorrectly posting to the area instead.
I might not be explaining this right, but if you load up the project, run it, and try to submit the login form on the homepage it will break. Look at the form action and you will see what I mean.
Ah, I see what you mean now. This looks like a bug in the MvcFutures code. I've opened a ticket to get this fixed in MVC 3, but since MvcFutures is unsupported fixing this particular issue won't be a high priority compared to our other work.
Marked as answer by wleingang on Mar 15, 2010 04:30 PM
wleingang
Member
1 Points
3 Posts
FormExtensions make wrong paths when adding area to site
Mar 12, 2010 07:16 PM|LINK
Hi - anyone run into this before?
We have a large mvc2 project and just added an area to it. Now some of the paths in our forms are messed up. We are using Strongly Typed actionlinks and formextensions.
Please look at the following demo: http://iamwill.com/AreaExample.zip
The form on this page is incorrectly submitting to the area.
I think it's related to routing or just the way that area's are figured out when it's not specified.
Any guidance would be much appreciated!
Will
Areas MVC - 2 RC2
levib
Star
7702 Points
1099 Posts
Microsoft
Re: FormExtensions make wrong paths when adding area to site
Mar 13, 2010 12:13 AM|LINK
Change these calls in LogOnUserControl.ascx:
ActionLink() will never generate a link to a different area unless explicitly asked to. So, when within the Cabinets area, the first ActionLink() call above is staying within the current area, hence the incorrect URLs. The second call is explicitly annotated as "I don't care which area you're currently in, I want to go back to the root (empty string) area." The null parameter is necessary so that you're calling the correct ActionLink() overload.
wleingang
Member
1 Points
3 Posts
Re: FormExtensions make wrong paths when adding area to site
Mar 14, 2010 09:01 PM|LINK
I am doing that in some places, but when you aren't in that area, why would you have to specify area=""?
In the code you can plainly see there is a bug in how it decides to apply the area to the link incorrectly.
Will
levib
Star
7702 Points
1099 Posts
Microsoft
Re: FormExtensions make wrong paths when adding area to site
Mar 14, 2010 10:07 PM|LINK
Can you describe what you believe the bug is? The answer I gave above is correct for the specific case of the Login links.
wleingang
Member
1 Points
3 Posts
Re: FormExtensions make wrong paths when adding area to site
Mar 15, 2010 01:46 PM|LINK
Yeah- If you take a look at the form on the home page you can see that it's adding the Area to the path of the form action. The homepage is in the root area, but it's incorrectly posting to the area instead.
I might not be explaining this right, but if you load up the project, run it, and try to submit the login form on the homepage it will break. Look at the form action and you will see what I mean.
levib
Star
7702 Points
1099 Posts
Microsoft
Re: FormExtensions make wrong paths when adding area to site
Mar 15, 2010 04:18 PM|LINK
Ah, I see what you mean now. This looks like a bug in the MvcFutures code. I've opened a ticket to get this fixed in MVC 3, but since MvcFutures is unsupported fixing this particular issue won't be a high priority compared to our other work.