I just found
Sitecore.Context.Items object as part of the
Sitecore.Context. What is the use-case of using it and when I shouldn't use it?
I just found
Sitecore.Context.Items is a collection that exists for the lifetime of the http request. I use that collection for times when I need to store some data as part of a request where I will need that later.
My use case might be resolving a wildcard item during the
httpRequestBegin pipeline (just an example, you could resolve the wildcard item in a different pipeline). We want to keep the wildcard item as the
Context.Item so that the presentation pulled from that item, but there are multiple components on the page that need to use the resolved item for content.
The flow might be:
httpRequestBegin resolve item, add it to
Component1 try to get the cached item from
Sitecore.Context.Items, if its not there try to resolve it and add it to the collection
Component2 rinse and repeat the step from
There will be other use cases too. But basically, its just a request scoped collection that you can use to store objects.
Caveat: The above example, is just an example, I'm not saying this is the way you should resolve wildcard items ;)
So it has already been answered, but I feel I can add to it.
The use case is, if you have something going on early in a request cycle that you want to share or use later. As mentioned, the most common use-case is for Wildcard item resolving. But it can also be used for cross component communication.
Asp.Net already gives you
HttpContext.Current.Items which has the same functionality. As Richard says in his answer, for the "lifetime of the current request".
Sitecore.Context.Items has the advantage, that it can be used outside a HttpRequest. Like in a background job or a publishing job. You don't have to worry about whether you're in the scope of an actual request or not.
As such it is, in many cases, preferable to use - over the generic
HttpContext.Current may be null.
Items are a collection (Dictionary) of (Item or other) objects with a key. Some examples of items that are kept in this collection:
- Current item
- Current job (if a background job is running)
- Current language
- Content database (database that is being edited - normally master)
All of these can (and should) be fetched through their own properties within the Context. The reason to do so is because those calls might do something more on top of getting the value.
So actually it is like a request scoped collection.