I think this might be a bug, but I'd like to ask first whether there is a new way of extending the Doc Type tree?
I've created a new tree that extends umbraco.loadNodeTypes which works in terms of the tree, howvever I can't now edit a doc type, instead I get the exception:
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Looking into this, it seems originate from umbraco.settings.EditContentTypeNew.Page_Load which looks like this:
protected void Page_Load(object sender, EventArgs e) { this.dt = new DocumentType(int.Parse(base.Request.QueryString["id"])); if (!this.Page.IsPostBack) { this.bindTemplates(); base.ClientTools.SetActiveTreeType(TreeDefinitionCollection.Instance.FindTree<loadNodeTypes>().Tree.Alias).SyncTree(this.dt.Id.ToString(), false); } }
I'm guessing (as I can't debug into it) the the problem is the FindTree call, which is hard coded to look for the default loadNodeTypes tree implementation.
So, before I report this as a bug, does anybody know of a new way in 4.5 to extend an existing menu that I might not be aware of?
Why can you not step into the code to debug? I think the source for the core of 4.5 should be on CodePlex so you can download it and step through the code if you attach the debugger to your IIS process.
I think it's more to do with my laptop to be honest, it's not letting me debug properly. Will download the source though and see if I can pinpoint the issue.
Replied on Codeplex, but maybe easier to run dialog here:
The edit document type does indeed needs a reference to the default doctype tree in order to be able to mark which doctype is currently edited. The only solution for your issue would be to replicate the functionality in the EditContentTypeNew.ascx. Would be great if it was easy to extend this part of Umbraco, but unfortunately that's not the case. What are you trying to achieve that makes you have to replace the tree?
In that case it might be better to just listen to the different tree events and inject items into the context menu collection before the node is rendered. I don't have a codesnippet at hand but that's the way we do it in the HQ. That way you extend instead of modify the core which is a little cleaner (IMHO - others might disagree :-))
That was my main reason for asking really, I wasn't sure if there was a better way to do it. I did it this way origionaly as it's the only example I could find, but if I can do the same with events, then yea, that sounds perfect.
Can't extend Doc Type tree in 4.5
I think this might be a bug, but I'd like to ask first whether there is a new way of extending the Doc Type tree?
I've created a new tree that extends umbraco.loadNodeTypes which works in terms of the tree, howvever I can't now edit a doc type, instead I get the exception:
Looking into this, it seems originate from umbraco.settings.EditContentTypeNew.Page_Load which looks like this:
I'm guessing (as I can't debug into it) the the problem is the FindTree call, which is hard coded to look for the default loadNodeTypes tree implementation.
So, before I report this as a bug, does anybody know of a new way in 4.5 to extend an existing menu that I might not be aware of?
Many thanks
Matt
Why can you not step into the code to debug? I think the source for the core of 4.5 should be on CodePlex so you can download it and step through the code if you attach the debugger to your IIS process.
I think it's more to do with my laptop to be honest, it's not letting me debug properly. Will download the source though and see if I can pinpoint the issue.
Cheers
Matt
Replied on Codeplex, but maybe easier to run dialog here:
The edit document type does indeed needs a reference to the default doctype tree in order to be able to mark which doctype is currently edited. The only solution for your issue would be to replicate the functionality in the EditContentTypeNew.ascx. Would be great if it was easy to extend this part of Umbraco, but unfortunately that's not the case. What are you trying to achieve that makes you have to replace the tree?
I just need to add additional items to the context menu, its for my master doc type switcher package.
Mat
In that case it might be better to just listen to the different tree events and inject items into the context menu collection before the node is rendered. I don't have a codesnippet at hand but that's the way we do it in the HQ. That way you extend instead of modify the core which is a little cleaner (IMHO - others might disagree :-))
Here's an example of my head (don't know if it builds, though!) [EDIT: has ApplicationBase doubled):
That sounds good to me.
That was my main reason for asking really, I wasn't sure if there was a better way to do it. I did it this way origionaly as it's the only example I could find, but if I can do the same with events, then yea, that sounds perfect.
Cheers Neils, I'll go do my homework =)
Mat
Sweet!
is working on a reply...