[Mono-bugs] [Bug 81366][Nor] New - SiteMap.CurrentNode [w/ fix]

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Thu Apr 12 23:19:15 EDT 2007


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by mmorano at mikeandwan.us.

http://bugzilla.ximian.com/show_bug.cgi?id=81366

--- shadow/81366	2007-04-12 23:19:15.000000000 -0400
+++ shadow/81366.tmp.16581	2007-04-12 23:19:15.000000000 -0400
@@ -0,0 +1,87 @@
+Bug#: 81366
+Product: Mono: Class Libraries
+Version: 1.2
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: Sys.Web
+AssignedTo: mhabersack at novell.com                            
+ReportedBy: mmorano at mikeandwan.us               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: SiteMap.CurrentNode [w/ fix]
+
+The current SiteMap.CurrentNode will only resolve when the node is
+contained in the default provider.  For a site I am porting, it makes use
+of the standard XmlSiteMapProvider as the default provider, and a custom
+site map provider as well.  For the primary navigation of the site, it
+binds a sitemapdatasource to a repeater and will highlight the current
+section of the site, by seeing if the current node is a descendant of the
+different main navigation areas by the following code:
+
+if(SiteMap.CurrentNode != null)
+{
+    if(node == SiteMap.CurrentNode || 
+       SiteMap.CurrentNode.IsDescendantOf(node))
+    {
+          link.CssClass = "selected";
+    }
+}
+
+On MS, the above works, setting the css class for the link which indicates
+you are in the specific section.  Currently, in mono, this does not work,
+as SiteMap.CurrentNode is null for pages that are "contained" in the custom
+SiteMapProvider (the non-default provider).
+
+After looking at the SiteMap.CurrentNode implementation, it only tries to
+obtain the current node by inspecting the default provider.  The patch
+below changes this behavior to scan all providers until it finds a matching
+node:
+
+Index: System.Web/SiteMap.cs
+===================================================================
+--- System.Web/SiteMap.cs       (revision 75665)
++++ System.Web/SiteMap.cs       (working copy)
+@@ -60,7 +60,7 @@
+                }
+ 
+                public static SiteMapNode CurrentNode { 
+-                       get { return Provider.CurrentNode; }
++                       get { return FindCurrentNode(); }
+                }
+ 
+                public static SiteMapNode RootNode { 
+@@ -92,6 +92,22 @@
+                        }
+                }
+ 
++               static SiteMapNode FindCurrentNode ()
++               {
++                       SiteMapNode node = null;
++
++                       foreach(SiteMapProvider provider in SiteMap.Providers)
++                       {
++                               node = provider.CurrentNode;
++
++                               if(node != null)
++                                       return node;
++                       }
++
++                       return null;
++               }
++
++
+ #if TARGET_JVM
+                const string SiteMap_provider = "SiteMap_provider";
+                const string SiteMap_providers = "SiteMap_providers";
+
+I am not sure how MS actually performs the scan, but it is able to properly
+resolve the node.  For example, it might always start trying to find the
+node via the default provider, and then scan the list of providers if the
+node was not found in the default, (skipping the default during the scan of
+course).


More information about the mono-bugs mailing list