EditContext vs. Item.Editing in Sitecore

So, the other day a co-worker asked me about my thoughts on using the EditContext class as opposed to using item.Editing for editing an item using the API in Sitecore.  I did a lot of research on the 2 and what the diferences are and decided to put this up for either someone to correct me in my conclusion or at least to share my findings in a way that might simplify things for others.

Ok.. so to start, lets start with the basics.  In Sitecore, when you want to edit an item using the API, you first need to put the item in Editing mode. Make your edits and then remove the item from edit mode.  Editing an item, in the simplest possible code would look something like this:

item.Fields["Title"].Value = "My New Title";

Now, as you can see, there’s a method that needs to place the item in the editing mode… plus you have to remember to remove the item from editing mode, plus make sure that the “user” that is doing so has permissions (and either use a securitydisabler or switch user context) as well as some other considerations less apparent than these.  Fortunately, Sitecore has included a class that provides a quick and easy way of doing this.  The above edit can be done instead with this:

using (new EditContext(item)) { item["Title"] = "My New Title"; }

The above statement does the same and more.  First of all, the EditContext constructor takes an item as a parameter and then does item.Editing.BeginEdit().  Also, since its declared in a using statement (since it inherits from IDisposable), the Dispose function is guaranteed to be called which automatically call the item.Editing.EndEdit() using optional boolean params (which I’ll talk about in a second) or the defaults (true, false). No muss, no fuss.

Now, as I mentioned.. there are some optional params.  One is that you can pass it the item with the SecurityCheck.Enable or SecurityCheck.Disable parameter.  Imagine if you wanted to update an item that is a dependency for another item that the user is editing that they do have access to but the dependency item is not one that the user has access to. This allows that to happen without the need to use a SecurityDisabler or switch user contexts.

More importantly, imho, is the other method signature which allows you to pass it 2 bool values that represent “UpdateStatistics” and “Silent”.

  • UpdateStatistics – This just lets you control whether or not the item statistics fields will be updated (when updated, who updated, etc.).  Among other scenarios, imagine a situation where you have a batch process that will reset a flag of some sort on your item, but want to leave the last edited by field to the person who actually did the edit.  Set this flag to false and it simply updates your items without the changing the statistics of the item.
  • Silent – This is a biggie! This lets you disable any of the Events that will be triggered by the edit… such as the Item:Saved event.  This is helpful in situations like the above mentioned batch job.  Say you wanted to update the flag, but don’t want to have that item now added to the publish queue.  Basically, setting this to true will simply update the value without triggering all the other stuff that happens next.

So basically, using the EditContext object does the same but it wraps everything up for you in a nice package.  Sitecore standards prefer the use of the EditContext class as a quick and easy way of editing an item. I think this is probably the case because it handles doing all the stuff that can be forgotten and lets the coder focus on what is to be edited without having to worry about all the other potentially bad things that can be forgotten.  In a nutshell, it still does all the same stuff as the item.Editing class but allows one to do so within a using context which wraps it all up nicely. It’s definitely my choice for making edits to an item using the API.

By the way, be careful with changing the Silent flag.  I recently saw an instance where a call that was being made in the custom method that was run when an item was created.  It checked for a certain value and if that field’s value matched the criteria, it updated another field’s value…. however, the silent flag was set to true with updateStatistics being false.  There were some odd things that happened.  Why they happened is a different story and unrelated, but what it amounted to was a mess where basically the item update triggered a new version to be created and then both item versions set to publish which was an even bigger mess.  You may see the logic in doing this, but as I’ve seen, it caused some unexpected results.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s