-
☆ A M B ☆
- 24,524 Posts
This snippet returns the ultimate parent of the current document. It is useful for setting the starting root folder for menu snippets to create submenus.
// UltimateParent - MODx snippet
// recursively searches the document tree
// and determines the "ultimate" parent
// (the one whose parent is 0)
// of the given document
//
// created 02 Nov 2005 by [email protected]
// released to the public domain
//
// Usage:
// [!Menusnippet?folderid =`[[UltimateParent]]`!]
// [!...!] form must be used so the inner snippet
// is parsed properly.
//
$id = $modx->documentIdentifier;
$pid = $modx->getParent($id,1,"id");
if($pid['id'] == 0) { return $id; }
while ($pid['id'] != 0) {
$id = $pid['id'];
$pid = $modx->getParent($id,1,"id");
}
return $id;
Thanks for sharing nice snippet Susan !
Best regards,
zi
I have long held the belief that when the page object is built, it should have some of this information built in. For example:
$modx->genes
could be an array of information about the pages leading back to the root. Each element in the array would be an array containing basic information such as: page id, show in menu, published, pagetitle (perhaps menutitle), etc. It may seem like collecting all this for every page from the current page back to the root would be overkill, but really, I think it would save processing. Most of the menu snippets I’ve written or seen perform this task independently. Therefore, if you have several types of navigation (say tabs, section menu, breadcrumbs), then a lot of the same information is being retrieved multiple times.
Susans snippet here about finding the top level section for styling is yet another use for this kind of information. The "ultimate parent" would simply be the last one in the array (or first depending on how the genes array was built). So instead of performing multiple db queries, a page object could be quickly referenced. Then a menu could be built, a stylesheet could be associated, a language could be selected... whatever.
I don’t know. It wouldn’t work for every situation of course, but it seems like it might have enough merit to consider.
Standard Disclaimer
I could be totally wrong.
-
MODX Staff
- 12,272 Posts
That’s a very cool idea Jared! It’s very little overhead to store a bit of extra information related to each page, but would save a lot of processing time potentially. Very very cool... I like it!
Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
-
MODX Staff
- 12,272 Posts
Yes indeed. Next to no perceptible overhead in DB size for a lot of improvement in performance for things that need access to a page’s genealogy.
Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
-
MODX Staff
- 10,725 Posts
+1 on this from me, though I think the best option would be to allow this to be specified per page instance, or be automatically calculated if not specified (per page override). This geneology information could also be used to improve the friendly alias path implementation, allowing such sites to be built with full portability (e.g. using relative paths).
-
MODX Staff
- 12,272 Posts
Jason, want to take a stab at implementing this?
Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
Quote from: OpenGeek at Nov 16, 2005, 11:21 AM...This geneology information could also be used to improve the friendly alias path implementation...
Yeah, I think that’s what I’m getting at. This information, if available consistently by default, could be used for many things. Mostly navigation related, but not necessarily.
Standard Disclaimer
I could be totally wrong.
