For ease of maintainence you could set them as variables within the xslt vs hardcoding them. That way they are all at the top of the xslt and you don't need to search the code to make changes.
I try to go with nodeTypeAlias and/or tree structure for lookups, so I don't have to worry about resetting individual id's when moving from dev to test to prod.
You could either use a bit of .net to read a .config file (possibly over-kill in this situation) or you could use the built-in xslt document() function.
You would obviously need the config file to be valid xml, but you could then parse it in your xslt to get the item you were looking for.
Another option is to use a custom docType for the 'configuration' section of information that is outside your main content tree. Then you can use $currentPage/ancestor-or-self::root/node[@nodeTypeAlias = 'configSection']/blahblahblah. That would keep you from using the id directly and might be faster than reading an external file.
Hard coded node ids in XSLT
I often end up referring to node id's directly within XSLT when nodes are outside of the website (for look ups for example)
Something like:
<xsl:for-each select="umbraco.library:GetXmlNodeById('16572')"> .... </xsl:for-each>This works fine but I'd prefer to have these values in a config file or similar somewhere and refer to them by name so I can keep track.
Just wondering what how others deal with this?
Cheers
Rich
.
For ease of maintainence you could set them as variables within the xslt vs hardcoding them. That way they are all at the top of the xslt and you don't need to search the code to make changes.
-Chris
I try to go with nodeTypeAlias and/or tree structure for lookups, so I don't have to worry about resetting individual id's when moving from dev to test to prod.
Thanks guys.
@Chris this is slightly better thanks, I would still have to hunt through each XSLT file though.
@Jeff this would be the preferred method, though sometimes it's just easier to refer by id.
Is there an easy way to read config values in XSLT?
Hi, Rich,
You could either use a bit of .net to read a .config file (possibly over-kill in this situation) or you could use the built-in xslt document() function.
For example...
You would obviously need the config file to be valid xml, but you could then parse it in your xslt to get the item you were looking for.
Another option is to use a custom docType for the 'configuration' section of information that is outside your main content tree. Then you can use $currentPage/ancestor-or-self::root/node[@nodeTypeAlias = 'configSection']/blahblahblah. That would keep you from using the id directly and might be faster than reading an external file.
Let us know what you finally decide.
cheers,
doug.
is working on a reply...