Background
DotNetNuke supports the ability to give a URL a custom page name, to make the URL more human friendly, e.g. instead of /Page/itemId/14/Default.aspx
, you can have /Page/itemId/14/My-Article.aspx
. The API for achieving this is via DotNetNuke.Common.Globals.FriendlyUrl
(which just calls DotNetNuke.Services.Url.FriendlyUrl.FriendlyUrlProvider.FriendlyUrl
).
This FriendlyUrl
method has some overloads which take a path
and pageName
parameter, where you can specify the meaningful querystring parameters via path
and the friendly page name via pageName
. Following an example from Bruce Chapman, that might look something like this:
FriendlyUrlProvider.Instance().FriendlyUrl(tab, "~/Default.aspx?TabId=" + tab.TabID, "My_Custom_Page_N开发者_StackOverflowame.aspx")
Problem
My issue with this approach is that the URL only gets the parameters that I directly specify in that path
parameter. Using the standard, non-friendly approach with Globals.NavigateURL
, I'll get additional parameters based on the current context and the portal's settings (most notably, language
). I'd prefer to not have to reimplement/copy the NavigateURL
implementation, but I don't see any other choice. Bruce has an issue in DNN's Gemini issue tracker that would add a pageName
parameter to Globals.NavigateURL
, but it's been sitting there for quite a while without getting any attention.
Another issue is that I have to hard-code ".aspx" onto the page name, rather than letting the friendly URL provider decide what the extension should be (or whether to go without an extension altogether).
Am I missing something, or is copying the core NavigateURL
my best option for getting full support for friendly page names in URLs?
One slight enhancement to the above is to call Globals.ApplicationURL(tabId)
to get the "~/Default.aspx?TabID=x"
part of the URL. You still have to manually add the language
parameter, though...
精彩评论