I've been extending the CMS's content tree to hide some menu items for sections that can't be edited (so they're visible, but not editable). It's only for two sections, so I'm just checking the node ids. So far, so good. Now, I want to make it so that all of the children of one of these items only have the delete option in the context menu.
In my BeforeNodeRender() code, it looks like the node items in the XmlTree have no knowledge of their parent. I could just create a document from the node id, but I'm wary that this site will have a LOT of content, so I don't really want to add the extra overhead if I can avoid it. Is there an easy way to check the parent id of the currently rendering node?
Hmmmmmmm, after a bit of playing, it looks like the XmlTreeNode that's rendered has no idea of it's place in the menu hierarchy.......
I came up with a few ways to do this, after grubbing through the core for a bit and scratching my head:
Use the NodeFactory to create the node and check it's values. This avoids the database hit as it comes from the XML cache, but doesn't work if the node hasn't been published yet, so no good.
Create a CMSNode using the id of the node in the XmlTreeNode that's passed into the BeforeRender event, and check it's parent. This is ok, but the parent id is private, you can only get the parent object, meaning that you're going to end up with at least 2 database calls (one to create the item you're on, and one for the parent object), I only had a quick look at the classes in the Core, so it's possible that there may be more per instantiation. This will get run on every content item that gets added to the menu, so potential performance hit ahoy.
Create a Document using the node id of the XmlTreeNode, which has the same issue as a CMSNode, in that it returns the entire parent, resulting in double the amount of database traffic, and the Document object looks like it incurs more of an overhead than the CMSNode does.
The items in the section I'm looking at all have the same custom icon. I can check the Icon property of the XmlTreeNode and if it's my custom item I can change the menu. This is a horrendous hack, and I can hear kittens exploding in the distance just for mentioning it, but it does work! :P
The menu items are loaded in by tree.aspx, and the ajax call that gets the nodes passes in the id of the page that it wants to load in the children for on the querstring of the get request it makes to populate the menu. In the BeforeRender code you can check the querystring for "id" and compare that to the id of the section you want to affect the child items in. This works nicely, has very little overhead compared to the others, but almost definitely won't work in 4.1, where the menu tree has been completely rewritten.
I've ended up going with 5, as the nicest of the bunch. I'd still be interested to know if there's a better way of doing this, if anyone has done something similar and can offer any advice, it'd be greatly appreciated!
Checking a CMS node's parent id
Hi,
I've been extending the CMS's content tree to hide some menu items for sections that can't be edited (so they're visible, but not editable). It's only for two sections, so I'm just checking the node ids. So far, so good. Now, I want to make it so that all of the children of one of these items only have the delete option in the context menu.
In my BeforeNodeRender() code, it looks like the node items in the XmlTree have no knowledge of their parent. I could just create a document from the node id, but I'm wary that this site will have a LOT of content, so I don't really want to add the extra overhead if I can avoid it. Is there an easy way to check the parent id of the currently rendering node?
Hmmmmmmm, after a bit of playing, it looks like the XmlTreeNode that's rendered has no idea of it's place in the menu hierarchy.......
I came up with a few ways to do this, after grubbing through the core for a bit and scratching my head:
I've ended up going with 5, as the nicest of the bunch. I'd still be interested to know if there's a better way of doing this, if anyone has done something similar and can offer any advice, it'd be greatly appreciated!
:)
is working on a reply...