Fixes: U4-4223 MVC based forms with SurfaceControllers don't work when rendered in Webforms mode.

This slightly changes how the routing works in the module, now we always send the request to the RenderRouteHandler, this will first process the logic for route hijacking, then it will determine if the request was found to be a WebForms template, if so then we'll return the webforms handler. This also now allows us to have POSTed values to SurfaceController's from forms that have been rendered in Webforms whilst maintaining all viewdata, tempdata and model state on postback even when rendering in webforms!
This commit is contained in:
Shannon
2014-02-13 13:19:51 +11:00
parent f9323c85e4
commit 9827b40bea
5 changed files with 122 additions and 70 deletions

View File

@@ -395,7 +395,8 @@ namespace Umbraco.Web
#endregion
/// <summary>
/// Rewrites to the correct Umbraco handler, either WebForms or Mvc
/// Rewrites to the Umbraco handler - we always send the request via our MVC rendering engine, this will deal with
/// requests destined for webforms.
/// </summary>
/// <param name="context"></param>
/// <param name="pcr"> </param>
@@ -406,49 +407,24 @@ namespace Umbraco.Web
// rewritten url, but this is not what we want!
// read: http://forums.iis.net/t/1146511.aspx
string query = pcr.Uri.Query.TrimStart(new[] { '?' });
var query = pcr.Uri.Query.TrimStart(new[] { '?' });
string rewritePath;
// GlobalSettings.Path has already been through IOHelper.ResolveUrl() so it begins with / and vdir (if any)
var rewritePath = GlobalSettings.Path.TrimEnd(new[] { '/' }) + "/RenderMvc";
// rewrite the path to the path of the handler (i.e. /umbraco/RenderMvc)
context.RewritePath(rewritePath, "", query, false);
if (pcr.RenderingEngine == RenderingEngine.Unknown)
{
// Unkwnown means that no template was found. Default to Mvc because Mvc supports hijacking
// routes which sometimes doesn't require a template since the developer may want full control
// over the rendering. Can't do it in WebForms, so Mvc it is. And Mvc will also handle what to
// do if no template or hijacked route is exist.
pcr.RenderingEngine = RenderingEngine.Mvc;
}
switch (pcr.RenderingEngine)
{
case RenderingEngine.Mvc:
// GlobalSettings.Path has already been through IOHelper.ResolveUrl() so it begins with / and vdir (if any)
rewritePath = GlobalSettings.Path.TrimEnd(new[] { '/' }) + "/RenderMvc";
// rewrite the path to the path of the handler (i.e. /umbraco/RenderMvc)
context.RewritePath(rewritePath, "", query, false);
//if it is MVC we need to do something special, we are not using TransferRequest as this will
//require us to rewrite the path with query strings and then reparse the query strings, this would
//also mean that we need to handle IIS 7 vs pre-IIS 7 differently. Instead we are just going to create
//an instance of the UrlRoutingModule and call it's PostResolveRequestCache method. This does:
// * Looks up the route based on the new rewritten URL
// * Creates the RequestContext with all route parameters and then executes the correct handler that matches the route
//we also cannot re-create this functionality because the setter for the HttpContext.Request.RequestContext is internal
//so really, this is pretty much the only way without using Server.TransferRequest and if we did that, we'd have to rethink
//a bunch of things!
var urlRouting = new UrlRoutingModule();
urlRouting.PostResolveRequestCache(context);
break;
case RenderingEngine.WebForms:
rewritePath = "~/default.aspx";
// rewrite the path to the path of the handler (i.e. default.aspx)
context.RewritePath(rewritePath, "", query, false);
break;
default:
throw new Exception("Invalid RenderingEngine.");
}
//if it is MVC we need to do something special, we are not using TransferRequest as this will
//require us to rewrite the path with query strings and then reparse the query strings, this would
//also mean that we need to handle IIS 7 vs pre-IIS 7 differently. Instead we are just going to create
//an instance of the UrlRoutingModule and call it's PostResolveRequestCache method. This does:
// * Looks up the route based on the new rewritten URL
// * Creates the RequestContext with all route parameters and then executes the correct handler that matches the route
//we also cannot re-create this functionality because the setter for the HttpContext.Request.RequestContext is internal
//so really, this is pretty much the only way without using Server.TransferRequest and if we did that, we'd have to rethink
//a bunch of things!
var urlRouting = new UrlRoutingModule();
urlRouting.PostResolveRequestCache(context);
}
/// <summary>