Asp. NET routing system: generating URLs based on routing rules

As we mentioned earlier, the ASP.net routing system is mainly used in two aspects, one is to realize the separation of the request and physical address through the matching of the registration URL template and the physical file path, and the other is to generate a corresponding URL through the registered routing test. The latter is implemented by invoking the GetVirtualPath method of the RouteCollection type.

As shown in the following code snippet, GetVirtualPath defines two GetVirtualPath method overloads, Their common parameter requestcontext and values represent the request context (the encapsulation of the Routedata and HTTP contexts) and the values used to replace the variable position characters defined in the URL template. The other GetVirtualPath method has an additional string parameter name that represents the registered name of the routing object that is specifically used in the collection (the first parameter specified when the Mappageroute method is invoked). Appendtrailingslash and Lowercaseurls decide whether to add a "/" character (if not) when the generated URL is normalized, and whether the URL needs to be converted to lowercase.

   1:public class Routecollection:collection<routebase>
   2: {
   3:     //other Members
   4: Public     virtualpathdata GetVirtualPath (RequestContext requestcontext, routevaluedictionary values);
   5: Public     virtualpathdata GetVirtualPath (RequestContext requestcontext, string name, routevaluedictionary values) ;
   6:
   7: Public     bool Appendtrailingslash {get  ;  Set }
   8: Public     bool Lowercaseurls {get  ;  Set }
   9:}

If no specific routing object is specified when the GetVirtualPath method is invoked, each routing object of the entire collection is traversed and its GetVirtualPath method is called, and if the returned virtualpathdata does not NULL, it is directly treated as a return value , otherwise (no matching route object found) returns NULL. If a specific routed object is identified in the call to GetVirtualPath, the GetVirtualPath method of the routed object is called directly and its execution results are returned.

When we call the GetVirtualPath method, we can pass in NULL as the first argument (RequestContext), In this case, a RequestContext object is created based on the current HTTP context (corresponding to the HttpContext static property present) as an argument that invokes the GetVirtualPath method of the Routing object. This parameter contains an empty Routedata object. If the current HTTP context does not exist, a InvalidOperationException exception is thrown directly.

Route matching for the GetVirtualPath method only requires that the values of the variables defined in the URL template be available, and that the values of these variables have three sources, respectively, the default variable values for the Routing object definition, Specifies the variable value (values attribute) provided by the RequestContext Routedata and the manually supplied variable value (the RouteValueDictionary object specified by the values argument), and the selection priority of these three variable values is from low to high. Also, for example, the URL template for getting weather information previously defined, the following is the route registration code.

   1:public class Global:System.Web.HttpApplication
   2: {
   3:     protected void Application_Start (object sender, EventArgs e)
   4:     {
   5:         var defaults = new RouteValueDictionary {{"AreaCode", "010"}, {"Days", 2}};
   6:         var constaints = new RouteValueDictionary {{"AreaCode", @ "0\d{2,3}"}, {"Days", @ "[1-3]{1}"}};
   7:         var datatokens = new RouteValueDictionary {{"defaultcity", "BeiJing"}, {"Defaultdays", 2}};
   8:         RouteTable.Routes.MapPageRoute ("default", "{areacode}/{days}", "~/weather.aspx", false, defaults, Constaints, Datatokens);
   9:     }
  10:}

We generate three specific URLs in the background code of the Weather.aspx page by calling RouteTable and routes familiar GetVirtualPath methods if the following code calls.

1:public Partial class Weather:page
2: {
3:protected void Page_Load (object sender, EventArgs e)
4: {
5:routedata routedata = new Routedata ();
6:routedata.values.add ("AreaCode", "0512");
7:routedata.values.add ("Days", "1");
8:requestcontext RequestContext = new RequestContext ();
9:requestcontext.httpcontext = new Httpcontextwrapper (httpcontext.current);
10:requestcontext.routedata = Routedata;
11:
12:routevaluedictionary values = new RouteValueDictionary ();
13:values. ADD ("AreaCode", "028");
14:values. ADD ("Days", "3");
15:
16:response.write (RouteTable.Routes.GetVirtualPath (null,null). VirtualPath + "<br/>");
17:response.write (RouteTable.Routes.GetVirtualPath (RequestContext, NULL). VirtualPath + "<br/>");
18:response.write (RouteTable.Routes.GetVirtualPath (RequestContext, values). VirtualPath + "<br/>");
19:}
20:}

From the code snippet above, we can see that the first call to the GetVirtualPath method transmits the RequestContext and values arguments null, and the second specifies a manually created RequestContext object. Its routedata values attribute has two variables (Areacode=0512;days=1), while the values argument is still null; for the third time, we specify specific objects for the parameter RequestContext and values. The latter contains two parameters (areacode=028;days=3). Accessing the Weather.aspx page on the browser will get the 3 URLs shown in the following figure. This fully confirms the aforementioned conclusions about variable-selection precedence.

This article supporting source code: http://www.bianceng.net/dotnet/201211/593.htm