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.
|
Do you find this information helpful? Please log in to provide feedback.