FAQ

General

Why do we always need a lifecycle state named "initial" in a lifecycle definition?

When defining a lifecycle via a SCXML, you can specify the permissions that are allowed at each state in the lifecycle. The first state in a lifecycle needs to always be initial as ES needs to maintain this virtual state to execute the initial permission logic when the initial state change occurs. When an asset is created, ES automatically promotes the asset from the initial state to the created state and assigns the respective permissions. Note that the initial state is a virtual state and that the created state is the first logical state.

ES Extension Model

What technologies should I be aware of before working with the ES Extension Model?

Handlebars (v1.0.0) templating engine as ES uses Handlebars for both server and client side templates. For more information go to, http://handlebarsjs.com/.

What are the main differences between an asset extension and an app extension?

• In ES, an asset extension is designed to apply customizations to an individual asset type; while, the app extension is designed to apply customizations to the whole app, which will affect all the asset types.

• The app.js script is a mandatory file unlike the asset.js file.

• The asset extension allows partials to be altered without specifying a controller; whereas, in an app extension a controller must be present for the ES rendering framework to attempt to pick up resources in the themes directory.

What is a partial?

All of the views found in the Store and Publisher also consists of a number nested smaller views. Each of these views are referred to a partial, which is defined in a  .hbs  file (e.g., header.hbs).

Why are some partial definitions empty?

The partial definitions of some partials (such as, sidebar-container.hbs and extended-search-attributes.hbs) are empty, because they are placeholder partials, which do not have any actual implementation on the ES side.

What is meant by creating the shell of an asset extension?

When extending an asset for the purpose of customizing new asset types, you need to create a specific folder structure for the asset extension. The folder structure for each customized asset type is referred to as the shell of an asset extension. This folder structure is vital for the asset extension model to work. For more information, see Asset Extension.

What are the elements that an asset extension directory contains?

An asset extension directory will contain the following elements: 

• A themes directory with one or more themes (Optional).
• An asset.js file (Optional).
• A pages directory (Optional).
• An apis directory (Optional).

What is an overriding controller?

When overriding a page, you need to create a copy of the default controller, add it into the pages directory of the respective asset extension or app extension, and thereafter update the controller. The newly updated controller is the overriding controller.

What are the rules that apply when creating a new page in ES with the existing views?

1. The controller (.jag file) that serves the new page should have the minimum code to invoke the Caramel renderer method.
2. The file structure in the renderers directory should mimic the path to the controller.
3. The renderer should have the same name as the controller. 

For more information on how to create a new page with the existing ES view, see Adding a New Page with the Existing Views.

What is the general rule that applies when overriding a page or API?

As a general rule of thumb, you can override any page or API in the default asset extension pages or apis directory. 

Can I override an existing global API?

No, you can not override an existing API, which is globally accessible. However, if needed you can create a new global API. For more information, see Adding a New Global API.

When should I restart ES after doing a change to one of my extensions?

• After changing any asset.js or app.js files.

• After adding or removing an asset or app extension folder.
  
  

Handlebars

What is an HBS file?

The .hbs extension is used by Handlebars template files.
 

Are there any good Handlebars tutorials?

Go to http://handlebarsjs.com/ for handlebar tutorials.

Locations of key ES files and directories

Where are the RXT definitions for asset types stored?

All the RXT definitions for the new asset types are available in the <ES_HOME>/repository/resources/rxts directory.

Where are the lifecycle definitions for asset types stored?

All the SCXML files, which contain the lifecycle definitions, are available in the <ES_HOME>/repository/deployment/server/jaggeryapps/publisher/config/lifecycles directory.
 

Where is the default asset extension for the Publisher located?

It is located in the <ES_HOME>/ repository/deployment/server/jaggeryapps/publisher/extensions/assets/default/asset.js  file.
 

Where is the default asset extension for the Store located?

It is located in the <ES_HOME>/ repository/deployment/server/jaggeryapps/store/extensions/assets/default/asset.js  file.
 

Where are the default partials for the Publisher located?

It is located in the <ES_HOME>/repository/deployment/server/jaggeryapps/publisher/themes/default/partials directory.
 

Where are the default partials for the Store located?

It is located in the <ES_HOME>/repository/deployment/server/jaggeryapps/store/themes/store/partials directory.
 

Where should Publisher asset extensions be stored?

Publisher asset extensions need to be stored in the  <ES_HOME>/repository/deployment/server/jaggeryapps/publisher/extensions/assets directory.
 

Where should Store asset extensions be stored?

Store asset extensions need to be stored in the <ES_HOME>/repository/deployment/server/jaggeryapps/store/extensions/assets directory.