G
Guest
Is it a problem to attach Non-static site map providers under one that
inherits from StaticSiteMapProvider ?
We are implementing a custom site map provider for a website that is being
converted to ASP.NET 2.0. The conversion is going well because some of the
features, like Master Pages and Site Maps, of ASP.NET 2.0 allow us to migrate
away from a "top frame" style of navigation to a standard dynamic cascading
top menu with minimal coding on our existing pages. We already have a rather
complex database that contains our entitlements (or roles) that we need to
leverage in a custom site map provider, but we wanted to replace our existing
hard-coded home page links with a top-level XmlSiteMapProvider which appears
to have most of the features that we need.
So our Site map will be
XmlSiteMapProvider (that references nodes and ...)
-> One or more CustomSiteMapProviders
However, the two SiteMapProviders that we will be working with
(XmlSiteMapProvider with securityTrimming ON and our CustomSiteMapProvider
that loads links from the database) use different paradigms for loading their
site maps. The XmlSiteMapProvider (inherits from StaticSiteMapProvider)
loads from the sitemap config file initially into a static representation of
the data. The Custom SiteMapProvider dynamically loads the links from the
database seperately for each user and stores each user's sitemap temporarily
in the cache. The reason for this is that the business logic for getting the
links for each user within this provider are implemented in the data-layer
and are rather complex. (not a simple role-based access scenario). Trying
to unravel these entitlements into a list of roles for each of these links
will introduce a lot of complexity and also exceed the number of nodes that
are recommended for use with the XmlSiteMapProvider and securityTrimming.
What we are confused about is how this is handled by the XmlSiteMapProvider.
Although the source for this provider is posted on MSDN (see ScottGu's Blog)
it is also not the "FULL" source in that it does not divulge how the
XmlSiteMapProvider attaches to other child providers except for other
XmlSiteMapProviders. It looks like when it builds the sitemap for it's child
providers, it checks [EnsureChildProvidersUpToDate()] to see if the root node
[GetRootNodeCore()] for each child provider has changed since the last
traversal. If so, then it seems to rebuild the child provider and re-attach
it to it's static site map structure. In our case, I'm not sure how this
would play out because I'm not sure that our provider fits the original
design intent for a provider to attach under a StaticSiteMapProvider.
For example, it is likely that the child provider will be out of date on
each request because it will be a different user accessing the website. This
would cause a rebuild of the SiteMapNodes from the non-static provider and
their attachment to the Static siteMap structure. (If they do get attached -
we really can't tell because that section of the source may be missing.)
Would all of this refreshing of data in the static collections cause
threading contention? Is it possible that both threads will be adding nodes
at the same time?
Another concern is that the algorithm that the
EnsureChildProviderIsUpToDate() method uses to determine whether the
siteMapNodes in a child provider need refreshed may not be sufficient in our
case. User (1) and User(2) may have the same root node, but different
children. If the algorithm is only comparing the parents, it may not notice
this difference. Again, we do not know what the XmlSiteMapProvider is doing
to handle the case when a non-static Site Map Provider is a child of it, as
this may not be in the source we possess.
If someone on the development team for SiteMapProviders could comment, we
would appreciate it. Likewise, divulging the full source code for
XmlSiteMapProvider may also answer our question.
Alexander P. Brown
The P. stands for Provider
inherits from StaticSiteMapProvider ?
We are implementing a custom site map provider for a website that is being
converted to ASP.NET 2.0. The conversion is going well because some of the
features, like Master Pages and Site Maps, of ASP.NET 2.0 allow us to migrate
away from a "top frame" style of navigation to a standard dynamic cascading
top menu with minimal coding on our existing pages. We already have a rather
complex database that contains our entitlements (or roles) that we need to
leverage in a custom site map provider, but we wanted to replace our existing
hard-coded home page links with a top-level XmlSiteMapProvider which appears
to have most of the features that we need.
So our Site map will be
XmlSiteMapProvider (that references nodes and ...)
-> One or more CustomSiteMapProviders
However, the two SiteMapProviders that we will be working with
(XmlSiteMapProvider with securityTrimming ON and our CustomSiteMapProvider
that loads links from the database) use different paradigms for loading their
site maps. The XmlSiteMapProvider (inherits from StaticSiteMapProvider)
loads from the sitemap config file initially into a static representation of
the data. The Custom SiteMapProvider dynamically loads the links from the
database seperately for each user and stores each user's sitemap temporarily
in the cache. The reason for this is that the business logic for getting the
links for each user within this provider are implemented in the data-layer
and are rather complex. (not a simple role-based access scenario). Trying
to unravel these entitlements into a list of roles for each of these links
will introduce a lot of complexity and also exceed the number of nodes that
are recommended for use with the XmlSiteMapProvider and securityTrimming.
What we are confused about is how this is handled by the XmlSiteMapProvider.
Although the source for this provider is posted on MSDN (see ScottGu's Blog)
it is also not the "FULL" source in that it does not divulge how the
XmlSiteMapProvider attaches to other child providers except for other
XmlSiteMapProviders. It looks like when it builds the sitemap for it's child
providers, it checks [EnsureChildProvidersUpToDate()] to see if the root node
[GetRootNodeCore()] for each child provider has changed since the last
traversal. If so, then it seems to rebuild the child provider and re-attach
it to it's static site map structure. In our case, I'm not sure how this
would play out because I'm not sure that our provider fits the original
design intent for a provider to attach under a StaticSiteMapProvider.
For example, it is likely that the child provider will be out of date on
each request because it will be a different user accessing the website. This
would cause a rebuild of the SiteMapNodes from the non-static provider and
their attachment to the Static siteMap structure. (If they do get attached -
we really can't tell because that section of the source may be missing.)
Would all of this refreshing of data in the static collections cause
threading contention? Is it possible that both threads will be adding nodes
at the same time?
Another concern is that the algorithm that the
EnsureChildProviderIsUpToDate() method uses to determine whether the
siteMapNodes in a child provider need refreshed may not be sufficient in our
case. User (1) and User(2) may have the same root node, but different
children. If the algorithm is only comparing the parents, it may not notice
this difference. Again, we do not know what the XmlSiteMapProvider is doing
to handle the case when a non-static Site Map Provider is a child of it, as
this may not be in the source we possess.
If someone on the development team for SiteMapProviders could comment, we
would appreciate it. Likewise, divulging the full source code for
XmlSiteMapProvider may also answer our question.
Alexander P. Brown
The P. stands for Provider