Optimizing Friendly URL for Page Providers
Page Providers are often used to integrate flat external data without a hierarchy. Since everything in EPiServer CMS assumes you have a nice hierarchy you simulate a hierarchy by for example categories or date of creation (i.e. /MyProvider/2009/04/28/My-Data-Item/).
The FriendlyURLRewriteProvider will find the actual page by recursively calling GetChildren and looking at the property PageURLSegment. There are 2 issues you can run into:
1) The URLs are not permanent, you may base your simulated structure on something that will change very often.
2) Performance issues, your backing store is slow or contains large amount of content that you do not want to load into memory just to evaluate a URL (in case you don’t display a tree based on this structure on the site, otherwise this makes no sense since it eventually will be loaded anyway).
The approach taken by me is to:
1) Add an identifier on the PageURLSegment property for your data item so we can use that identifier to resolve pages instead of the friendly URL. This way everything plays nice with EPiServer CMS and the “default” friendly URL would continue to work even without our module.
2) Hook into the URL rewriter and take over those incoming URLs that need to be resolved and use the identifier instead.
The first step is simple, just extend your page provider and add the unique identifier (I am basing this example on the Northwind provider by Allan).
1: pd.URLSegment += "." + pd.PageLink.ID.ToString();
Now we get URLs like “/MyProvider/2009/04/28/My-Data-Item.3434/” and they should work just fine, next step is to hook into the URL rewriter and take over those. I use a HttpModule for that that needs to be registered in web.config.
1: public void Init(HttpApplication context)
3: // This method will be called multiple times for every HttpApplication, since the UrlRewriteModule has one
4: // instance per application with non-static events this is perfectly fine.
5: UrlRewriteModule m = context.Modules["UrlRewriteModule"] as UrlRewriteModule;
7: throw new Exception("Cannot find a http module with name UrlRewriteModule");
9: m.HttpRewritingToInternal += new EventHandler<UrlRewriteEventArgs>(m_HttpRewritingToInternal);
The next step is to find “our” URLs so that we can cancel the built-in resolver and make our own lookups:
1: private void m_HttpRewritingToInternal(object sender, UrlRewriteEventArgs e)
3: if (e.Cancel || e.Url==null)
8: // Don't do anything when edit-mode passes id=xx since then no parsing is needed
9: if (e.Url.QueryCollection["id"] != null)
14: // Locking is handled in Init-method
20: // Check if the path follows "our" pattern
21: Match match = _urlValidate.Match(e.Url.Path);
22: if (!match.Success)
27: // Now verify that the path is rooted on our page provider,
28: // we do not cache this path since the page could be moved
29: string url = GetFriendlyURL(_entryPoint);
30: if (e.Url.Path.ToString().StartsWith(url,true,CultureInfo.CurrentCulture))
32: PageReference pageLink;
34: // Try to parse the "id" baked into the URL
35: if (PageReference.TryParse(match.Groups["id"].Value, out pageLink))
37: //Get the page from our page provider
38: PageData page = DataFactory.Instance.GetPage(new PageReference(pageLink.ID,PageProviderName));
40: // Rewrite the path and keep any query strings
41: Url urlStaticLink = new Url(page.StaticLinkURL);
42: e.Url.Path = urlStaticLink.Path;
45: // Let EPi know we did some changes
46: e.IsModified = true;
47: e.Internal = page.PageLink;
48: e.Cancel = true;
You need to add handling of invalid URLs to this sample. For example if someone changes the URL to “/MyProvider/2009/04/28/I-hate-you.3434/” it would continue to work since we only are looking at the identifier. You need to figure this out by comparing the incoming URL to the actual data and redirect the users to the correct URL instead, I’ve seen sites that do not handle this and its a type of ugly injection that can be misused. Consider yourself warned.
Download the demo source