Programming Microsoft ASP.NET 4 - Dino Esposito [190]
No code is required to use a SiteMapPath control. All that you have to do is place the following markup in the .aspx source file:
As you can guess, style properties in the preceding markup are not essential to make the control work and can be omitted for brevity.
Note
Style properties that most ASP.NET server controls expose represent the heart of the ongoing conflict between themes and CSS styles. Style properties form an alternate—in a way, a higher level—syntax to style controls. In the end, it boils down to a sort of architecture choice: if you choose to go with server controls, use style properties (and themes), but at that point ignore CSS and client-side configurations. Otherwise, ignore themes and style properties and take more care of the emitted markup. In this case, however, are you sure you’re still OK with ASP.NET Web Forms?
Configuring the Site Map
There are various ways to further configure the site map file to address specific real-world scenarios. For example, you can tie together distinct site map files, localize the title and description of pages, and serve each user a site map that complies with his or her roles in the application’s security infrastructure. Let’s tackle each of these situations.
Using Multiple Site Map Files
As mentioned, the default site map provider reads its information from the web.sitemap file located in the application’s root directory. Additional .sitemap files written according to the same XML schema can be used to describe portions of the site.
The idea is that each The content of each of the child site map files is injected in the final tree representation of the data at the exact point where the link appears in the root web.sitemap file. Child site map files can be located in child directories if you desire. The value assigned to the siteMapFile attribute is the virtual path of the file in the context of the current application. Note that in this case all site map files are processed by the same site map provider component—the default XmlSiteMapProvider component. In the previous section, we examined a scenario where different providers were used to process distinct sections of the site map. The two features are not mutually exclusive and, in the end, you can have a default site map file that spans multiple .sitemap files, with portions of it provided by a different provider. In this case, as you’ve seen, all settings for the custom provider must be set in the web.config file. Securing ASP.NET Site Maps A feature known as site map security trimming provides a way to hide navigational links in a site map based on security roles. Enabled on the site map provider and individual nodes, security trimming serves user-specific views of a site. It does only that, though. It hides links from view whenever the content of the site map is displayed through
Most Web sites require that only certain members be allowed to see certain pages. How should you specify that in a site map? The most effective and efficient approach is using roles. Basically, you associate each node in the site map with a list of authorized roles, and the ASP.NET infrastructure guarantees that no unauthorized users will ever view that page through the site map. This approach is advantageous because you define roles and map them to users once—for security purposes and membership—and use them also for site maps.