Configuration issues - there's a simple way to support old style config with minor changes in location

[hidegh]

Hi,

i use your MvcSiteMapProvider (with multiple files, with splitted level 1-2 and level 3 menu), recently i upgraded to the MVC4 version.

The changes are noticeable, (hierarchical) role resolving is better than in the old version. BUT THE NEW WAY OF CONFIGURING (mainly configuring multiple site-map files) is simply awful.

Ok, possibly you cannot have your config inside the providers tag, but why haven't you created a new MvcSiteMapSetting node, where the old style of configuration (with multiple providers and so) is picked up by your framework and used to configure the MvcSiteMapProvider....

Would it be possible? Or again simpkly i'm the only one having multiple sitemaps in a single solution?

[NightOwl888]

There was one specific limitation with Microsoft's implementation that I needed a workaround for - I need to be able to create new web sites on the fly in my multi-tenant application and that simply wasn't possible with everything tied to web.config. The new design enables this scenario and can still use the web.config to store the SiteMap configuration as well. It also allows you to create multiple types of web sites, each with their SiteMapNodeProvider business logic that can essentially be templates for creating the website types.

It wouldn't be a good idea to use the exact same configuration settings that ASP.NET uses because that would end up enabling ASP.NET sitemaps so you would basically be running 2 copies of every SiteMap that is configured, and if you don't need interoperability with ASP.NET that would be a big waste of RAM. Not to mention, those settings aren't set up for adding child items with multiplicity.

This is actually the first complaint we have had about the configuration. I guess most people run a single SiteMap so it is not an issue, and most of the people with a more complex application are already using DI so it is not that big of a deal for them either. In particular, DI configured apps tend to steer clear of using XML to configure things because of their brittle nature.

The 4.5 release finally frees us up enough to be able to include a 1-to-1 ISiteMapCacheKeyToBuilderSetMapper implementation in the box without breaking the external DI configurations, which would greatly help ease this pain. However, changing the way that the SiteMapCacheKeyGenerator works by default (including getting the settings from web.config) is a breaking change that could only be done in a major release (v5).

I have been considering putting a <mvcSiteMap/> section in the web.config, migrating the settings again, but allowing the current settings to still work so it won't be a breaking change. The reason I have been considering it is to enable support for ISiteMapNodeProvider when using the internal DI container, which would eliminate the need to use DynamicNodeProvider (we would still support it, but new features including a fluent API would be added to ISiteMapNodeProvider first). This would enable multiple SiteMaps to be configured in the XML as well. The problem with our current configuration settings (in appSettings) are that they don't scale to provide multiplicity.

But then, the whole configuration in web.config idea was an afterthought that was thrown in at the last minute because it seemed unfair to push people into the DI world that weren't ready to go. Using web.config was just a set of training wheels to be used until you are ready to use DI. The fact of the matter is, if you can configure in DI, then you can build your own web.config settings at whim and call them whatever you want, but if you only support web.config settings, there is no way to enable DI configuration.

So to answer your question, yes it is possible. And if you don't want to wait for us to do it, you can do it in your own application yourself, and possibly even contribute your implementation. Just keep in mind that we don't want to fetch configuration settings directly anywhere except for the composition root, in the rest of the application they are handed to us through the constructor by the DI configuration.

BTW - I noticed you are using multiple sitemaps for multiple menus. You really don't need to do that now because you can use named menus and then hide the nodes you don't want to see in each using FilteredSiteMapNodeVisibilityProvider. In that scenario, there is no need for extra files.

[hidegh]

Thanx for the promt answer.

I've solved my problem by creating an additional level inside the sitemap and rendering menu from a given node, downwards...

var wwwParentNode = @Html.MvcSiteMap().SiteMap.RootNode.ChildNodes.First(i => i.Title == "Www");
@Html.MvcSiteMap().Menu("CustomMenuWww", wwwParentNode, true, false);


Anyhow, great project, lot of possibilities, flexible.

[NightOwl888]

Glad to hear you got it resolved. Marking this one closed.