I've noticed in 4.7 (maybe earlier) that umbraco.presentation.nodeFactory.Node has been marked as obsolete which means you get compiler warnings whenever you use it. Instead you are supposed to use umbraco.NodeFactory.Node.
Now, whilst I agree the latter namespace is much more logical, it leaves developers with a dilemma: Do I use the new, recommended Node class which will break on older Umbraco installations or do I stick with the old Node class and put-up with annoying compiler warnings and the possibility that it might be removed at any time in newer versions?
We started using the new namespace, just because it feels like the right thing to do.
Also we had a library with extension methods called Node.cs for the old namespace and I just created an INode.cs with extensions for the new namespace, works like a charm.
So my advice would be; use the new namespace for 4.7+ projects...
I agree the new namespace is much more logical and certainly "feels" better to use. The problem, though, is that it you are a company maintaining a large number of Umbraco 4.x sites and wish to develop (say) a new package to be used on all those sites then you can't use the new namespace without breaking compatability with older versions. In a perfect world it would be nice to just say something will be 4.7+ and screw the rest, but in reality you need to provide support for older versions in new code unless you want to isolate a large number of users.
So when deprecating stuff be aware of the implications for developers and the dilemmas it poses.... Maye it is best waiting for v5 to completely overhaul the existing legacy namespaces (which I agree are pretty poorly thought through)?
The only reason I stick with the legacy namespace for now is so that I can use uComponents uQuery. Lee tells me the next version of uComponents (not 3.0) will be compiled against 4.7+ instead of 4.5 which will be cool.
Why is umbraco.presentation.nodeFactory.Node deprecated?
I've noticed in 4.7 (maybe earlier) that umbraco.presentation.nodeFactory.Node has been marked as obsolete which means you get compiler warnings whenever you use it. Instead you are supposed to use umbraco.NodeFactory.Node.
Now, whilst I agree the latter namespace is much more logical, it leaves developers with a dilemma: Do I use the new, recommended Node class which will break on older Umbraco installations or do I stick with the old Node class and put-up with annoying compiler warnings and the possibility that it might be removed at any time in newer versions?
What do others think?
We started using the new namespace, just because it feels like the right thing to do.
Also we had a library with extension methods called Node.cs for the old namespace and I just created an INode.cs with extensions for the new namespace, works like a charm.
So my advice would be; use the new namespace for 4.7+ projects...
Thank you for the quick answer!
I agree the new namespace is much more logical and certainly "feels" better to use. The problem, though, is that it you are a company maintaining a large number of Umbraco 4.x sites and wish to develop (say) a new package to be used on all those sites then you can't use the new namespace without breaking compatability with older versions. In a perfect world it would be nice to just say something will be 4.7+ and screw the rest, but in reality you need to provide support for older versions in new code unless you want to isolate a large number of users.
So when deprecating stuff be aware of the implications for developers and the dilemmas it poses.... Maye it is best waiting for v5 to completely overhaul the existing legacy namespaces (which I agree are pretty poorly thought through)?
Well, I agree if you're developing a package and wish to keep it backwards compatible you should use the old namespace.
But when building a new website on 4.7 I'd use the new namespace.
The only reason I stick with the legacy namespace for now is so that I can use uComponents uQuery. Lee tells me the next version of uComponents (not 3.0) will be compiled against 4.7+ instead of 4.5 which will be cool.
is working on a reply...