November Happy Hour will be moved to Thursday December 5th.

Loading...
Area: Optimizely CMS
ARCHIVED This content is retired and no longer maintained. See the latest version here.

Recommended reading 

Table of contents

The Episerver user interface makes extensive use of the object store API available in the Dojo Toolkit. This topic describes  the implementation of object stores in Episerver and their recommended pattern for use.

Implementation in the Episerver user interface

To create an environment where object store data can be shared across components with minimal dependencies, we have created a epi.shell.store.Registry object. This object is responsible for maintaining a dictionary of key and object store pairs. For example:

JavaScript
var registry = dependency.resolve("epi.shell.store.Registry"),
    store = registry.add("epi.cms.pageversion", new Memory());

It also has a convenience method for creating epi.shell.store.Patchable stores.

JavaScript
var patchable = registry.create("epi.cms.pageversion", url, options);

An epi.shell.store.Patchable is essentially an epi.shell.store.JsonRest store which is wrapped with both cache and observable functionality, and having additional functionality to refresh and patch particular items in the store.

patch Updates an item in the object store cache and note on the server. The intention of this is to minify requests to the server but still populate updates to the user interface via the store.
refresh Will cause the item to be dropped from the cache store, if it exists, and the latest version retrieved from the server and put back into the cache.

Dependencies between object stores

You can have multiple object stores that have dependencies on each other. If you have an authoritative store with a subset of data stores as dependents, you can make updated to the authoritative store on the client and push those changes to the dependent stores with the patch method so they do not query the server again. 

For example, the content data store contains all the content (and associated property values) that was viewed or edited, which can be a lot of information. Widgets, like the page tree, need a subset of information placed in a separate store that depends on the content data store. You create this dependency using the addDependentStore method as shown in the following example:

JavaScript
var registry = dependency.resolve("epi.shell.store.Registry"),
    authoritative = registry.create("epi.cms.contentdata", url, options),
    dependent = registry.create("epi.cms.content.light", url, options);

authoritative.addDependentStore(dependent);

When you call patch or refresh on the authoritative store, changes also are populated through to the dependent store.

Using the stores

If you are creating a new store to use across multiple components, use epi.shell.store.Registry to create and register your store in an initialization module. Then you can retrieve it when needed and request the wanted store.

When you have a store, you can initialize the view for your component and look for other areas of the application that trigger an update in the component’s view. For example, the following page version component requests versions for a particular page from the server and listens to any changes to update the details in the list when an edit is made to the version.

JavaScript
var registry = dependency.resolve("epi.shell.store.Registry"),
    store = registry.get("epi.cms.contentversion"),
    query = store.query({
        id: 3,
        language: "en"
    });

query.observe(dojo.hitch(this, this.onChange));
query.then(function(results) {
    this.view.data = results;
});

If another part of the application calls add, put, delete, refresh, or patch and the data being modified matches the query, then the onChange method is triggered.

Available object stores

Store KeyDescription
epi.shell.context Used by the context manager to retrieve the current context. Is a cache of current and previous contexts.
epi.shell.profile Stores information about the current user profile.
epi.shell.metadata Contains metadata for an object or type. This is used to set up editing of content.
epi.cms.contentdata Contains content items such as pages and blocks with defined properties.
epi.cms.content.light Contains a light version of content, specifically containing properties needed for the page tree.
epi.cms.category Contains the CMS categories.
epi.cms.contentversion Contains information about versions of a content item.
Do you find this information helpful? Please log in to provide feedback.

Last updated: Sep 21, 2015

Recommended reading