ASP.Net GetXmlNodeByXPath with mutliple site roots
Hi Guys,
Using Umbraco 4.0.2.1, i ALWAYS have a menu included on my page, therefore i use the following source in a foreach in the xslt responsible for rendering the menu:
This used to work fine untill we decided to implement multilanguage using multiple site roots. Basicly, GetXmlNodeByPath('.') does not give a damn about the current site root and just starts with the very most top level node which i assume to be the Top level (System?) 'Content' node.
Actually, i'm not creating this site from scratch but editing an existing one and i had no influance in the initial development process, therefore i would like to make as few changes as possible.
My question is: What would be a good way of rendering the main menu with respect to the current active site root?
Altough i would be able to fall back to the area of my knowledge which is .NET and usercontrols on average and rewrite the submenu there, yet this would imply a major change and it excludes a learing change :)
Your right, the behaviour should be different although this is not in my case because i have a extra filter (only selecting those wo are children of a certain top-level document type).
I can recommend explicitly using the level filter due to the fact that it makes the code better understandable (you explicitly specify you only want the nodes from the top level.
@Criztian Very cool, I never thought of that! Because of the filter you only get one node back, clever. I do suppose it performs a LITTLE worse because of the filter, but it shouldn't be noticable.
@Sebastiaan: Would be cool to do some performance tests on that. My guess is the filter version is better performance wise, 'coz I think that's one of the areas where an XSLT processor goes out of its way to optimize stuff.
ASP.Net GetXmlNodeByXPath with mutliple site roots
Hi Guys,
Using Umbraco 4.0.2.1, i ALWAYS have a menu included on my page, therefore i use the following source in a foreach in the xslt responsible for rendering the menu:
umbraco.library:GetXmlNodeByXPath('.')/node[string(data [@alias='umbracoNaviHide']) != '1'
This used to work fine untill we decided to implement multilanguage using multiple site roots. Basicly, GetXmlNodeByPath('.') does not give a damn about the current site root and just starts with the very most top level node which i assume to be the Top level (System?) 'Content' node.
Actually, i'm not creating this site from scratch but editing an existing one and i had no influance in the initial development process, therefore i would like to make as few changes as possible.
My question is: What would be a good way of rendering the main menu with respect to the current active site root?
Altough i would be able to fall back to the area of my knowledge which is .NET and usercontrols on average and rewrite the submenu there, yet this would imply a major change and it excludes a learing change :)
Cheers in advance for helping me out!
Hi Polity,
You do not need that library method for this - you should be able to get a reference to the current site root like this:
- then use that in for-each/apply-templates to render nodes:
<xsl:for-each select="$siteRoot/node[not(data[@alias = 'umbracoNaviHide'] = 1)]"> ... </xsl:for-each>/Chriztian
You don't even need the @level = 1 because the root node is called "root", so ancestor-or-self::node will stop at level 1 anyway.
(which also means that you can still get to the root node outside of this site by doing ancestor-or-self::root).
@Sebastiaan: Not entirely correct sir :-)
Try this (when $currentPage is at, say, level 3 or 4):
versus this:
There's a difference, right?
/Chriztian
Works like a charm (also without the level filter as pointed out by Sebastiaan).
Thnx for the help
@Criztian,
Your right, the behaviour should be different although this is not in my case because i have a extra filter (only selecting those wo are children of a certain top-level document type).
I can recommend explicitly using the level filter due to the fact that it makes the code better understandable (you explicitly specify you only want the nodes from the top level.
@Criztian Very cool, I never thought of that! Because of the filter you only get one node back, clever. I do suppose it performs a LITTLE worse because of the filter, but it shouldn't be noticable.
@Sebastiaan: Would be cool to do some performance tests on that. My guess is the filter version is better performance wise, 'coz I think that's one of the areas where an XSLT processor goes out of its way to optimize stuff.
/Chriztian
is working on a reply...