I'm trying to fetch an url of a specific page. I'm to fetch the url from all pages on the site, since it's for a shopping cart link shown on all pages).
It has to be done from inside of an usercontrol (the rest of the usercontrol is stuff which cannot be done from a xslt macro).
The site is a multi-domain site, structured as shown below:
www.domain.dk - DA language root - ...all danish site pages... - EN language root - ...all english site pages... ...all other domains with same structure...
As you can see, the code first finds the current pages language root, then finds the specific shopping cart node. There is only one shopping cart node per language.
My problem is that the code which should fetch the language root (line 2), always finds the DA language root node, no matter which language the current node is a descendant of. I've checked the currentNode.current.OuterXML of currentNode, and everything look ok - it really does contain the xml for the current node.
This makes no sence to me - any ideas? Or maybe an idea for an entirely different approach? I've looked a bit into using the umbraco.presentation stuff instead, but cannot find a way of replacing the xslt descendant axis.
When i use the same xslt code from a xslt macro everything works perfectly:
The reason is because using // is effectively an XSLT wildcard, it'll match all documents to that criteria. Ancestor will look for all nodes of the doctype 'Language Folder' in the whole of Umbraco. The first to match this criteria according to your tree would be the DA folder.
XSLT from .Net - weird select problem
I'm trying to fetch an url of a specific page. I'm to fetch the url from all pages on the site, since it's for a shopping cart link shown on all pages).
It has to be done from inside of an usercontrol (the rest of the usercontrol is stuff which cannot be done from a xslt macro).
The site is a multi-domain site, structured as shown below:
www.domain.dk
- DA language root
- ...all danish site pages...
- EN language root
- ...all english site pages...
...all other domains with same structure...
I'm using the following code:
XPathNodeIterator currentNode = umbraco.library.GetXmlNodeCurrent();
XPathNavigator languageNode = currentNode.Current.SelectSingleNode("//ancestor::node[@nodeTypeAlias='Language Folder']");
XPathNavigator basketNode = languageNode.SelectSingleNode("//descendant::node[@nodeTypeAlias='Shopping Cart']");
int basketNodeId = Convert.ToInt32(basketNode.GetAttribute("id", ""));
string basketUrl = umbraco.library.NiceUrl(basketNodeId);
As you can see, the code first finds the current pages language root, then finds the specific shopping cart node. There is only one shopping cart node per language.
My problem is that the code which should fetch the language root (line 2), always finds the DA language root node, no matter which language the current node is a descendant of. I've checked the currentNode.current.OuterXML of currentNode, and everything look ok - it really does contain the xml for the current node.
This makes no sence to me - any ideas? Or maybe an idea for an entirely different approach? I've looked a bit into using the umbraco.presentation stuff instead, but cannot find a way of replacing the xslt descendant axis.
When i use the same xslt code from a xslt macro everything works perfectly:
<xsl:variable name="languageRoot" select="$currentPage/ancestor::node [@nodeTypeAlias='Language Folder']" />
or this works as well - but again only from a xslt macro:
<xsl:variable name="languageRoot" select="$currentPage/ancestor::node [@level=2]" />
Hey Rune,
Try replacing:
//ancestor::node[@nodeTypeAlias='Language Folder']
with:
ancestor::node[@nodeTypeAlias='Language Folder']
The reason is because using // is effectively an XSLT wildcard, it'll match all documents to that criteria. Ancestor will look for all nodes of the doctype 'Language Folder' in the whole of Umbraco. The first to match this criteria according to your tree would be the DA folder.
Hope this helps.
Benjamin
Hello Benjamin
That did the trick - thank you for your help :-)
/Rune
is working on a reply...