Just "crawl" the page tree using the ParentLink of each page to construct the page path. Unless you do it on an exceptional scale it will be a very cheap operation performance-wise.
I'm already doing that, Magnus - I just wondered if there might be a better way to walk up the tree than having to hydrate a pagedata from each page's parentlink in order to get the parent's parent. If that's as cheap as you say then I'll stick with it. Most of it will be cached anyway.
I'm still wondering if there's anyway I can get hold of that PagePath data through the API, though!
There is a method DataFactory.Instance.GetParents that will give you a PagePath instance. However that API is uncached (for the LocalPageProvider at least) so I would suggest Magnus approach in most cases.
Hi Johan,
Is there any reason why the GetParents is not cached? Finally I thought I found a way to avoid crawling of the page tree...
The reason we do not cache it for now is that if we cached it we should have a strategy/algorithm implemented for when to evict the items from cache. That is something that we might add in future but that is not in place now.
Hi Johan,
thanks for your answer! I use this GetParents to find out which segment a user is in when navigating the site. For each request i use GetParents. Is this potentially dangerous for performance?
It is often hard to give a straigth answer when it comes to performance. My advice would be to measure it. You could e.g. first do some measurement with your implementation and then compare it with an implementation that traverse parent chain. Remember though that the first time parent chain is walked might take more time due to cache misses.
Each row in tblPage has a value in the PagePath column that represents the IDs of its ancestors. Is there any way I can get hold of this using the API? I was hoping that the PagePath type might be the way to get to it but apparently not, unless I am using it incorrectly.