Skip to content

v4.3.0
Compare
Choose a tag to compare
@NightOwl888 NightOwl888 released this 12 Sep 22:35
· 272 commits to master since this release
v4.3.0
d5e6a4e

This is the most significant release since 4.0.0. There are some behavioral changes to be aware of and some manual updating of configuration code is highly recommended (but not required) if you are using an external DI container.

Important Default Behavioral Changes

Orphaned Node Detection

Up until this release, you could declare nodes as MvcSiteMapProviderAttribute or Dynamic Node Providers that specified a ParentKey that doesn't exist and you would neither see the orphaned node in your HTML helpers or get an error.

This has changed. We now use logic that ensures your configuration is valid or it will throw an exception. The exception message contains detailed information about which nodes could not be added to the sitemap as well as where they originated from.

When upgrading, you should take this into consideration, as you might need to spend some time fixing orphaned node problems.

XML Nested Dynamic Node Provider Processing

The default logic of processing nested DynamicNodeProviders in XML has changed. Take the following XML for example:

<mvcSiteMapNode title="VendorDetails" dynamicNodeProvider="MyNamespace.VendorDetailsDynamicNodeProvider, MyAssembly">
    <mvcSiteMapNode title="VendorAPIDetails" dynamicNodeProvider="MyNamespace.VendorAPIsDynamicNodeProvider, MyAssembly">
        <mvcSiteMapNode title="VendorAPITableDetails" dynamicNodeProvider="MyNamespace.VendorAPIVirtualTablesDynamicNodeProvider, MyAssembly"/>
    </mvcSiteMapNode>
</mvcSiteMapNode>

Up until this release, the logic would first call VendorDetailsDynamicNodeProvider. For each node that was returned from that provider, VendorAPIsDynamicNodeProvider would be called one time and then it would be called one final time at the end. In short, it would be called N + 1 times.

In turn, the VendorAPIsDynamicNodeProvider would call the VendorAPIVirtualTablesDynamicNodeProvider N + 1 times. So for example if our VendorDetailsDynamicNodeProvider returned 10 nodes, and our VendorAPIsDynamicNodeProvider returned 10 nodes, VendorAPIsDynamicNodeProvider would be called 11 times, and VendorAPIVirtualTablesDynamicNodeProvider would be called 111 times.

This behavior was clearly broken, and the default logic now calls each DynamicNodeProvider 1 time per declaration in the XML whether they are nested or not.

In other words, the above configuration will produce exactly the same result as this one.

<mvcSiteMapNode title="VendorDetails" dynamicNodeProvider="MyNamespace.VendorDetailsDynamicNodeProvider, MyAssembly"/>
<mvcSiteMapNode title="VendorAPIDetails" dynamicNodeProvider="MyNamespace.VendorAPIsDynamicNodeProvider, MyAssembly"/>
<mvcSiteMapNode title="VendorAPITableDetails" dynamicNodeProvider="MyNamespace.VendorAPIVirtualTablesDynamicNodeProvider, MyAssembly"/>

If for some reason you managed to get an application working with that anomalous behavior and it now requires it, there is a web.config setting MvcSiteMapProvider_EnableSiteMapFileNestedDynamicNodeRecursion that can be used to re-enable it. If you are using an external DI configuration, this setting can be found on the constructor of the XmlSiteMapNodeProvider and is named useNestedDynamicNodeRecursion.

We don't recommend using this setting unless you absolutely require it, and even then we highly recommend you either move your recursion logic inside of a DynamicNodeProvider or you change your application so it doesn't require recursion at all (it could probably perform much better than it does). This configuration setting will likely disappear in a future major release.

Important External DI Configuration Update

There is a major design change in this release to fix node processing order problems, but to avoid breaking backward compatibility some existing features were deprecated instead of removed. That means you don't have to do this, but we highly recommend you do or you won't be taking advantage of the latest bug fixes or future updates to the code.

Please see the diff in commit 425c15cdfef7ee70b3226845daf2f91c8d3d7f12 and use it as a guide to update your DI configuration.

SiteMapPreserveRouteDataAttribute Deprecated

The SiteMapPreserveRouteData attribute has gone the way of the Dodo bird. After careful analysis, it was determined that this attribute has no useful purpose. It is scheduled for removal in v5.

The recommended alternative is to use the preservedRouteParameters collection of the SiteMap node. For a detailed look at how to make this work, read How to Make MvcSiteMapProvider Remember a User's Position.

Change Log

  1. Bug: Fix for #223, no error message when parent node doesn't exist in the SiteMap. An error message is now shown with each orphan that couldn't be added to the SiteMap and detailed information about the origin of the node.
  2. Feature: Closes #114, specify order of nodes in the menu. Added an order property that can be used throughout the provider to control the order in the Menu and SiteMap HTML helpers.
  3. Bug: Fixed datatype of Attributes property in DynamicNode and MvcSiteMapNodeAttribute. It was IDictionary<string, string>, changed it to be IDictionary<string, object> so user-defined objects can more easily be added to the SiteMap nodes.
  4. Deprecated: SiteMapPreserveRouteDataAttribute was deprecated because upon careful analysis it has no real-world use. It apparently depended on writing data to the shared SiteMap cache in order to function. Allowing updates to the shared cache was a bug that was fixed with the release of 4.0.17.
  5. Enhancement: Made MvcSiteMapProvider_IncludeAssembliesForScan, MvcSiteMapProvider_AttributesToIgnore, and MvcSiteMapProvider_ControllerTypeResolverAreaNamespacesToIgnore configuration settings safer by trimming the whitespace between the value and delimiter.
  6. Enhancement: Added an error message when the .sitemap file doesn't have a root node defined.
  7. Feature: Added setting MvcSiteMapProvider_EnableSiteMapFile so XML file parsing can be disabled while using the internal DI container.
  8. Bug: Fixed the logic so it doesn't depend on the order the nodes are processed when adding Dynamic Nodes and MvcSiteMapNodeAttribute defined nodes to the SiteMap. This was causing nodes not to be added with no indication as to the cause. This change required a new interface to be created, ISiteMapNodeProvider and the following types were deprecated: XmlSiteMapBuilder, ReflectionSiteMapBuilder, AspNetSiteMapBuilder, DynamicNodeBuilder, and IDynamicNodeBuilder.
  9. Bug: Fixed instantiation of providers when using them in conjunction with MvcSiteMapNodeAttribute and the internal DI container.
  10. Feature: Added MvcSiteMapProvider_IncludeRootNodeFromSiteMapFile setting to allow parsing of the XML without including its root node. This allows multiple XML files to used to specify a single SiteMap.
  11. Bug: Fixed logic that processes Dynamic Nodes that are nested in the XML file so it only calls them 1 time per declaration (rather than N + 1 times, N being the number of nodes in the parent Dynamic Node provider).
  12. Added MvcSiteMapProvider_EnableSiteMapFileNestedDynamicNodeRecursion setting to enable V3 dynamic node recursion behavior, which called the nested dynamic node N+1 times (not sure why or how it could possibly be useful, but we need this setting on the off chance that someone is using it). The default behavior is to have this setting disabled, and we don't recommend enabling it unless you absolutely need the recursion for your application to work.
  13. Fixed implicit resource key by setting it to the SiteMapCacheKey as described in #228 as the "object key".
Assets 2
Loading