OK I submitted this post by accident and the forum throws an error when I try to edit it, so here's the real question:
I've got a date folder system for events with the following structure that corresponds to a date property on the event Document Type:
2011 -03 --event
When saving and publishing an event it checks if the year and month nodes exist and creates them if needed, then moves the event node into its corresponding parent month node. The tree is refreshing whenever a month node is created (by calling ClientTools.SyncTree), but if the month node already exists and I just try to move the node then the tree doesn't remember the position (even though I'm still calling ClientTools.SyncTree) and collapses back to the root home node. Has anybody had any problems with ClientTools.SyncTree not working properly when moving nodes to existing parent nodes?
Withouth knowing exactly what the ClientTools.SyncTree() methods does, wouldn't it be enough to call umbraco.library.RefreshContent() instead? :-) That's what I did when I'm creating the structure you're working on.
Hi Bo, I'm also calling RefreshContent() but it doesn't seem to work. The ClientTools.SyncTree() works if I call it before RefreshContent() . Its strange because if I'm creating a parent node, and then moving the document to the newly created parent then its fine, but the same code (without the creation of the parent node) then the tree collapses. I'm doing all of this in the Document.AfterSave event handler.
I think I've just solved it by calling SyncTree and passing in the parent of the parent path, eg. umbraco.BasePages.BasePage.Current.ClientTools.SyncTree(documentObject.Parent.Parent.Path, true);
Previously I was just calling it with the parent path, eg. umbraco.BasePages.BasePage.Current.ClientTools.SyncTree(documentObject.Parent.Path, true);
Don't know why it works one way and not the other.
ClientTools.SyncTree not working when moving a Document
I've got a date folder system that moves an event to a year->month node
2011
-03
umbraco.BasePages.BasePage.Current.ClientTools.SyncTree(documentObject.Parent.Path, true);
OK I submitted this post by accident and the forum throws an error when I try to edit it, so here's the real question:
I've got a date folder system for events with the following structure that corresponds to a date property on the event Document Type:
2011
-03
--event
When saving and publishing an event it checks if the year and month nodes exist and creates them if needed, then moves the event node into its corresponding parent month node. The tree is refreshing whenever a month node is created (by calling ClientTools.SyncTree), but if the month node already exists and I just try to move the node then the tree doesn't remember the position (even though I'm still calling ClientTools.SyncTree) and collapses back to the root home node. Has anybody had any problems with ClientTools.SyncTree not working properly when moving nodes to existing parent nodes?
Hi jonok,
Withouth knowing exactly what the ClientTools.SyncTree() methods does, wouldn't it be enough to call umbraco.library.RefreshContent() instead? :-) That's what I did when I'm creating the structure you're working on.
Hi Bo, I'm also calling RefreshContent() but it doesn't seem to work. The ClientTools.SyncTree() works if I call it before RefreshContent() . Its strange because if I'm creating a parent node, and then moving the document to the newly created parent then its fine, but the same code (without the creation of the parent node) then the tree collapses. I'm doing all of this in the Document.AfterSave event handler.
I think I've just solved it by calling SyncTree and passing in the parent of the parent path, eg.
umbraco.BasePages.BasePage.Current.ClientTools.SyncTree(documentObject.Parent.Parent.Path, true);
Previously I was just calling it with the parent path, eg.
umbraco.BasePages.BasePage.Current.ClientTools.SyncTree(documentObject.Parent.Path, true);
Don't know why it works one way and not the other.
I'm not sure if this is the correct approach - but it seems to do the job.
Cheers
is working on a reply...