First; I don't think this is a bug. The INode/Node combination works perfectly well, and as you noticed it is placed in another namespace than the old nodeFactory, which means old code won't break since the old nodeFactory is still in the assemblies.
Working with the new NodeFactory I would write your second example like this:
Node n = new Node(1234);
INode p = n.Parent;
// or
Node p = (Node) n.Parent;
Depending on what you need exactly. More often than not, an INode is perfectly adequate, and I would stick to the first parent declaration.
Checking with Reflector reveals the following methods and properties on INode
So as you see there's a lot of stuff available for you. I'm especially fond of the new ChildrenAsList property, which is very useful with Linq-2-objects, meaning you can easily do stuff like:
var node = new Node(1234);
var textPages = node.ChildreAsList.Where(c => c.NodeTypeAlias == "textPage");
NodeFactory and INode interface (4.6.1)
Hello Umbraco colleagues,
This is a follow up question to an earlier post:
our.umbraco.org/forum/developers/api-questions/17742-Get-Parent-Node-using-C-(461)
Since the umbraco.presentation.nodeFactory is obsolete, I want to get behind the new umbraco.NodeFactory classes.
When using umbraco.presentation.nodeFactory, this works:
but using umbraco.NodeFactory, the "n.Parent" reference produces an error.
This is the workaround (thanks Tom Fulton):
The error for n.Parent is going to break a fair amount of code and I'm sure others may have the same issue.
Two questions:
1) Should I report this as a bug?
2) Is there any more info somewhere on how to use the new INode interface to do cool new things?
Thanks,
David Hill
Hi David,
First; I don't think this is a bug. The INode/Node combination works perfectly well, and as you noticed it is placed in another namespace than the old nodeFactory, which means old code won't break since the old nodeFactory is still in the assemblies.
Working with the new NodeFactory I would write your second example like this:
Depending on what you need exactly. More often than not, an INode is perfectly adequate, and I would stick to the first parent declaration.
Checking with Reflector reveals the following methods and properties on INode
So as you see there's a lot of stuff available for you. I'm especially fond of the new ChildrenAsList property, which is very useful with Linq-2-objects, meaning you can easily do stuff like:
Regards
Jesper Hauge
Hi Jesper,
Thank you very much for the good information. Makes more sense now.
I'm sure I will be taking advanage of the additional functionality.
David
is working on a reply...