Craig100, the error you are getting probably says "Node 1234 has been orphaned and doesn't belong to a DynamicNodeList," correct? Sadly, I don't know of a way to do what you are trying. My other approach was to say @Model.AncestorOrSelf(1).Next().whatever but this suffers the same problem.
My working solution on this problem is to bite the bullet and use the ID hardcoded into my scripts. (We also tweak the backend right-click context menus to hide the "Delete" option on this special node so that the client doesn't break their site, and gives us peace of mind that the ID won't ever change!!) You could probably also put this ID into a web.config application variable or a global const to make a little easier to maintain.
Another approach, if you ever worry about the Settings node disappearing or really needing to change ID some day, is to have a content picker on your homepage and require someone to pick the NodeID of the settings node. Then you at least won't have to hardcode any numbers into your script, but again, it depends on how likely this scenario will be for you.
DynamicNodeContext sibling?
In a V6.1.2.2 webforms site I'm trying to work out the DynamicNodeContext equivalent of
@Model.AncestorOrSelf(1).Sibling("Settings").GetPropertyValue("footerText") I've used on another site using MVC.
At the moment I'm having to use
Library.NodeById(1068).introMusic.Any but I don't like using the ID as it could change.
My settings node is a sibling of home.
Any thoughts?
Thanks,
Craig
Hi Graig,
You could make use of descendants instead and get value of a particular docType?
@Model.AncestorOrSelf(1).Descendants("introMusic").Where(x=>x.Getproperty("umbracoNaviHide").Value != "True").Items;Craig100, the error you are getting probably says "Node 1234 has been orphaned and doesn't belong to a DynamicNodeList," correct? Sadly, I don't know of a way to do what you are trying. My other approach was to say
@Model.AncestorOrSelf(1).Next().whateverbut this suffers the same problem.My working solution on this problem is to bite the bullet and use the ID hardcoded into my scripts. (We also tweak the backend right-click context menus to hide the "Delete" option on this special node so that the client doesn't break their site, and gives us peace of mind that the ID won't ever change!!) You could probably also put this ID into a web.config application variable or a global const to make a little easier to maintain.
Another approach, if you ever worry about the Settings node disappearing or really needing to change ID some day, is to have a content picker on your homepage and require someone to pick the NodeID of the settings node. Then you at least won't have to hardcode any numbers into your script, but again, it depends on how likely this scenario will be for you.
Best of luck!
is working on a reply...