Hide menu Last updated: Mar 21 2013

Table of Contents

Introduction

The EPiServer user interface makes extensive use of the object store API available in the Dojo Toolkit. This documentation will look into 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:

CopyJavaScript
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.

CopyJavaScript
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, as well as 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 Objects Stores

One important concept in the architecture of the object stores in EPiServer is dependencies between stores; or the ability to have some form of authoritative store with stores containing a subset of data as dependents. This allows us to make updates to the authoritative store on the client and push those changes through to the dependent stores via the patch method so that they do not need to query the server again.

A good example of where this is helpful is the content data store. This store contains all the content which have been viewed or edited along with all of their property values. This can potentially be quite a lot of information. So for widgets like the page tree that display pages but only need a subset of information we have a separate store that we can make depend on the content data store.

Add this dependency using the addDependentStore method as shown in the following example:

CopyJavaScript
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);

Now when either patch or refresh are called on the authoritative store the changes will also be populated through to the dependent store.

Using the Stores

If you are creating a new store that will be used across multiple components it is recommended to use the 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.

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

CopyJavaScript
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;
});

Now 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 will be triggered.

Available Object Stores

Store Key Description
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 all 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.

Comments