Currently I am trying to figure out how I can add dynamic query string parameters to my sitemap navigation menu. For example, the user chooses the source and edition he wants to work with. I have a simple sitemap that creates navigational links but the parameters the user chose need to be passed in the query string. The default map looks like this:
<siteMapNode url="" title="" description="" >
<siteMapNode url="~/Image.aspx?location=Our Products" title="Our Products" description="Our Products" />
<siteMapNode url="~/Headline.aspx?location=Our Authors" title="Our Authors" description="Our Authors" />
</siteMapNode>
Now the links will need to have the parameters added dynamically depending on what was chosen by the user. For example:
<siteMapNode url="~/Image.aspx?location=Our Products&Source=12345&Edition=asdfff" title="Our Products" description="Our Products" />
<siteMapNode url="~/Headline.aspx?location=Our Authors&Source=12345&Edition=asdfff" title="Our Authors" description="Our Authors" />
Hopefully this is fairly clear. Let me know if anyone needs deeper explanation.
Thanks
Unfortunately, this is not supported by default. But you can implement the
SiteMap.SiteMapResolveevent in yourGlobal.asaxto catch such extended urls, and callSiteMapProvider.FindSiteMapNodewith the correct url:No need for custom
SiteMapProviders, this works with any provider.Now, if you want to be more dynamic, you can do several things, for example (there are may ways):
Flag all
<siteMapNode>tags with partial querystring matching with a special attribute, and load this list by iterating the entire sitemap. The problem with that approach is that this can be very inefficient for some sitemap providers (the file-based provider is an example of a provider that is a good match for such an approach). What you’d do then, is to say something likeIn code you could find such nodes recursively by starting at the root node, and remembering all nodes with a
queryStringFieldattribute:With this list in hand, and some hand waving, you should be able to do the same trick. Note that you should probably need to cache this list, because the
SiteMapResolveevent can be called more often than you’d expect. Especially for database-typeSiteMapProviders.