Using the new api with contentservice, I was going to copy a tree structure from a "system" folder in content to a newly created page.
Hooked up the created event on contentservice. Using the contentservice.copy to copy an exsisting structure, problem is that that copy persists data before the e.Entity is persisted, meaning the e.Entity.Id that is needed for parent id on the copy method is null.
The only way around this is to trigger an save of the e.Entity in the created event before attempting to copy a structure in under that entity.. This cant be the way to solve this....
Whats the reason behind not persisting the entity before created event handler fire? Why cant we have a children collection on the IContent that would have allowed to add new children that havent been persisted to database using the same "transaction" as its parent?
I would subscribe to the "Created" event on the ContentService, save the Content without firing events (which you can control) and then copy the pages.
public class CopyAfterNewlyCreated : IApplicationStartupHandler { public CopyAfterNewlyCreated() { ContentService.Created += ContentService_Created; }
public void ContentService_Created(IContentService sender, NewEventArgs<IContent> e) { sender.Save(content, 0, false);//Save without firing events sender.Copy(someContent, content.Id, false, 0); // 'someContent' being the content object you want to copy. } }
The legacy Document class does a similar thing by saving the unsaved Content item without firing a save event for that operation and then it does some more legacy stuff.
The ContentService.CreateContent method is only meant as a convenient way of creating a new content object based on the alias of a ContentType.
Yeah thats basiclly what I did. But it would have been nice that either the Content item is already persisted to db on the Created event, or that the content item or copy method could support this. Ie the content item could have a children collection that one could populate with a "clone" of the decendants from another content item. Or that copy could handle a not db stored parent reference.
Copy a content structure via API, when new parent is created? (6.0.3)
Using the new api with contentservice, I was going to copy a tree structure from a "system" folder in content to a newly created page.
Hooked up the created event on contentservice. Using the contentservice.copy to copy an exsisting structure, problem is that that copy persists data before the e.Entity is persisted, meaning the e.Entity.Id that is needed for parent id on the copy method is null.
The only way around this is to trigger an save of the e.Entity in the created event before attempting to copy a structure in under that entity.. This cant be the way to solve this....
Whats the reason behind not persisting the entity before created event handler fire? Why cant we have a children collection on the IContent that would have allowed to add new children that havent been persisted to database using the same "transaction" as its parent?
I would subscribe to the "Created" event on the ContentService, save the Content without firing events (which you can control) and then copy the pages.
The legacy Document class does a similar thing by saving the unsaved Content item without firing a save event for that operation and then it does some more legacy stuff.
The ContentService.CreateContent method is only meant as a convenient way of creating a new content object based on the alias of a ContentType.
- Morten
Yeah thats basiclly what I did. But it would have been nice that either the Content item is already persisted to db on the Created event, or that the content item or copy method could support this. Ie the content item could have a children collection that one could populate with a "clone" of the decendants from another content item. Or that copy could handle a not db stored parent reference.
is working on a reply...