Client Context has been superseded by ContextHub in the touch UI. Please see the related documentation for details.

The Client Context represents a dynamically assembled collection of user data. You can use the data to determine the content to show on a web page in a given situation (content targeting). The data is also available for web site analytics, and to any javascript on the page.

Client Context consists mainly of the following aspects:

The session store, that contains the user data.

The UI that displays the user data and provides tools for simulating the user experience.

To create a standalone session store and add it to Client Context, or create a session store that is tied to a Context Store component. AEM installs several Context Store components that you can use right away. You can use these components as a basis for your components.

For information about opening Client Context, configuring the information that it displays, and simulating the user experience, see Client Context.

Session Stores

The Client Context includes various session stores that contain user data. Store data comes from the following sources:

The Client Context framework provides a javascript API that you can use to interact with session stores to read and write user data, and listen and react to store events. You can also create session stores for user data that you use for content targeting or other purposes.

Session store data remains on the client. The Client Context does not write data back to the server. To send data to the server, use a form or develop custom javascript.

Each session store is a collection of property-value pairs. The session store represents a collection of data (of any kind), the conceptual meaning of which can be decided by the designer and/or developer. The following example javascript code defines an object that represents the profile data that session store might contain:

A session store can be persisted across browser sessions, or can last only for the browser session in which it is created.

Nota:

Store persistence uses either browser storage or cookies (the SessionPersistence cookie). Browser storage is more common.

When the browser is closed and reopened, a session store can be loaded with the values from a persisted store. Clearing the browser cache is then needed to remove the old values.

Context Store Components

A context store component is a CQ component that can be added to Client Context. Typically, context store components display data from a session store with which they are associated. However, the information that context store components display is not limited to session store data.

Page Data is no longer in the client context as a default component. If needed, you can add this by editing the client context, adding the Generic Store Properties component, then configuring this to define the Store as pagedata.

Targeted Content Delivery

Adding Client Context To A Page

Include the Client Context component to the body section of your web pages to enable Client Context. The path of the Client Context component node is /libs/cq/personalization/components/clientcontext. To include the component, add the following code to the JSP file of your page component, located just below the body element of your page:

Extending Client Context

Create a session store for the user data that you need for content targeting and web analytics.

Create a context store component to enable administrators to configure the associated session store, and to display store data in Client Context for testing purposes.

Nota:

If you have (or create) a JSONP service that can provide the data, you can simply use the JSONP context store component and map it to the JSONP service. This will handle the session store.

Creating a Session Store

Create a session store for the data that you need to add to and retrieve from Client Context. Generally, you use the following procedure to create a session store:

Create a client library folder that has a categories property value of personalization.stores.kernel. Client Context automatically loads the client libraries of this category.

Configure the client library folder so that it has a dependency on the personalization.core.kernel client library folder. The personalization.core.kernel client library provides the Client Context javascript API.

Add the javascript that creates and initializes the session store.

Including the javascript in the personalization.stores.kernel client library causes the store to be created when the Client Context framework is loaded.

Nota:

If you are creating a session store as part of a context store component, you can alternatively place the javascript in the init.js.jsp file of the component. In this case, the session store is created only if the component is added to Client Context.

Types of Session Stores

Session stores are either created and available during a browser session, or are persisted in browser storage or cookies. The Client Context javascript API defines several classes that represent both types of data stores:

CQ_Analytics.SessionStore: These objects reside only in the page DOM. The data is created and persisted during the lifetime of the page.

CQ_Analytics.PerstistedSessionStore: These objects reside in the page DOM and are persisted either in browser storage or cookies. The data is available across pages and across user sessions.

The API also provides extensions of these classes that are specialized for storing JSON data or JSONP data:

Creating the Session Store Object

The javascript of your client library folder creates and initializes the session store. The session store must then be registered using Context Store Manager. The following example creates and registers a CQ_Analytics.SessionStore object.

prolog.jsp and epilog.jsp: component interaction that allows you to add server side logic before or after the component rendering.

Complex data: Extend the GenericStore component. Your session store will then need a "renderer" method that will be called every time the component needs to be rendered. The renderer function is called with two parameters:

@param {String} store
The store to render

@param {String} divId
Id of the div into which the store has to be rendered.

Nota:

All Client Context components are extensions of either the Generic Store or Generic Store Properties components. Several examples are installed in the /libs/cq/personalization/components/contextstores folder.

Configuring the Appearance in Sidekick

When editing Client Context, context store components appear in Sidekick. As with all components, the componentGroup and jcr:title properties of the client context component determine the group and name of the component.

All components that have a componentGroup property value of Client Context appear in Sidekick by default. If you use a different value for the componentGroup property, you must manually add the component to Sidekick using Design mode.

Context Store Component Instances

When you add a context store component to Client Context, a node that represents the component instance is created below /etc/clientcontext/default/content/jcr:content/stores. This node contains the property values that are configured using the edit dialog of the component.

When Client Context is initialized, these nodes are processed.

Initializing the Associated Session Store

Add an init.js.jsp file to your component to generate javascript code that initializes the session store that your context store component uses. For example, use the intialization script to retrieve configuration properties for the component and use them to populate the session store.

The javascript that is generated is added to the page when Client Context is initialized on page load on both the author and publish instances. This JSP is executed before the context store component instance is loaded and rendered.

The code must set the mime type of the file to text/javascript, or it is not executed.

Precaución:

The init.js.jsp script is executed on the author and publish instance, but only if the context store component is added to Client Context.

The following procedure creates the init.js.jsp script file and adds the code that sets the correct mime type. The code that performs the store initialization would follow.

Rendering Session Store Data for genericstoreproperties Components

Displaying Property Data

The personalization taglib provides the personalization:storePropertyTag tag that displays the value of a property from a session store. To use the tag, include the following line of code in your JSP file:

The propertyName attribute is the name of the store property to display. The store attribute is the name of the registered store. The following example tag displays the value of the authorizableId property of the profile store:

HTML Structure

The personalization.ui client library folder (/etc/clientlibs/foundation/personalization/ui/themes/default) provides the CSS styles that Client Context uses to format the HTML code. The following code illustrates the suggested structure to use for displaying store data:

The /libs/cq/personalization/components/contextstores/profiledata context store component uses this structure to display data from the profile session store. The cq-cc-thumbnail class places the thumbnail image. The cq-cc-store-property-levelx classes format the alphanumeric data:

level0, level1, and level2 are distributed vertically, and use a white font.

level3, and any additional levels, are distributed horizontally, and use a white font with a darker background.

Rendering Session Store Data for genericstore Components

To render store data using a genericstore component, you need to:

Add the personalization:storeRendererTag tag to the component JSP script to identify the name of the session store.

Implement a renderer method on the session store class.

Identifying the genericstore Session Store

The personalization taglib provides the personalization:storePropertyTag tag that displays the value of a property from a session store. To use the tag, include the following line of code in your JSP file:

If you depend on another store, you need to cater for the case of when the store is never registered.

The following example uses the onStoreRegistered event of the profile session store. When the store is registered, a listener is added to the update event of the session store. When the store is updated, the content of the <div class="welcome"> element on the page is updated with the name from the profile store.

Excluding a Property from the sessionpersistence Cookie

To prevent a property of a PersistedSessionStore from being persisted (i.e. exclude it from the sessionpersistence cookie), add the property to the non-persisted property list of the persisted session store.

CQ_Analytics.ClientContextUtils.onStoreRegistered("surferinfo", function(store) {
//this will exclude the browser, OS and resolution properties of the surferinfo session store from the
store.setNonPersisted("browser");
store.setNonPersisted("OS");
store.setNonPersisted("resolution");
});

Configuring the Device Slider

Conditions

The current page must have a corresponding mobile page; this is determined only if page has a LiveCopy configured with a mobile rollout configuration (rolloutconfig.path.toLowerCase contains mobile).

Configuration

When switching from the desktop page to its mobile equivalent:

The DOM of the mobile page is loaded.

The main div (required) that contains the content, is extracted and injected into the current desktop page.

The CSS and body classes that need to be loaded need to be manually configured.

For example:

window.CQMobileSlider["geometrixx-outdoors"] = {
//CSS used by desktop that need to be removed when mobile
DESKTOP_CSS: [
"/etc/designs/${app}/clientlibs_desktop_v1.css"
],
//CSS used by mobile that need to be removed when desktop
MOBILE_CSS: [
"/etc/designs/${app}/clientlibs_mobile_v1.css"
],
//id of the content that needs to be removed when mobile
DESKTOP_MAIN_ID: "main",
//id of the content that needs to be removed when desktop
MOBILE_MAIN_ID: "main",
//body classes used by desktop that need to be removed when mobile
DESKTOP_BODY_CLASS: [
"page"
],
//body classes used by mobile that need to be removed when desktop
MOBILE_BODY_CLASS: [
"page-mobile"
]
};

Example: Creating a Custom Context Store Component

In this example, you create a context store component that retrieves data from an external service and stores it in the session store:

Extends the genericstoreproperties component.

Initializes a store using a CQ_Analytics.JSONPStore javascript object.

To open Client Context, press Ctrl-Alt-c (windows) or control-option-c (Mac).

Creating a Customized Client Context

To create a second client context you need to duplicate the branch:

/etc/clientcontext/default

The subfolder: /content
will contain the content of the customized client context.

The folder:/contextstores
allows you to define different configurations for the context stores.

To use your customized client context, edit the propertypath
in the design style of the client context component, as included in the page template. For example, as the standard location of: /libs/cq/personalization/components/clientcontext/design_dialog/items/path