Store architecture

Table of contents

• Introduction
• Implementation in the EPiServer User Interface
• Dependencies Between Objects Stores
• Using the Stores
• Available Object Stores

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:

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.

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.

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:

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.

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