Staging lets users change a Site without affecting the live Site and then publish all the changes in one fell swoop. If you include staging support in your application, your users can stage its content until it’s ready.

For example, if your application uses the Staging framework and provides information intended only during a specific holiday, users can save your application’s assets specific for that holiday. They reside in the Staging environment until they’re ready for publishing.

Staging and Export/Import share the same base framework. When publishing your staged content to the live Site, you’re essentially importing content from the staged Site and exporting it to the live Site. This means that implementing Staging in your app is almost the same as implementing the Export/Import framework. You can visit the Export/Import framework’s articles for the base APIs that both it and the Staging frameworks share.

If your app supports Export/Import, its entities (staged models) are automatically tracked by Staging with the use of data handlers. There are some Staging-specific configurations you can add that are not shared by Export/Import. Some Staging-specific actions you can complete include

  • Control Staging UI settings
  • Filter Staging-specific processes
  • Check for Staging-specific states

You’ll learn about these next.

Controlling Staging’s UI Settings

You can control most of Staging’s UI from your portlet data handler. This can be done several ways; first, you can configure predefined setter methods in the portlet data handler’s activate() method:

  • setStagingControls: adds fine grained controls over staging behavior that is rendered in the Staging UI. For example, this enables your app’s checkboxes in the Content section of the Publication screen. This is usually set like this: setStagingControls(getExportControls());. The staging UI typically provides the same content as the export UI (i.e., the Content section for selecting what to publish/export), so it leverages its UI. You can set the Staging UI differently by configuring the setStagingControls method differently. See the AssetTagsPortletDataHandler class for an example of not copying the Export UI for the Staging UI.
  • setDataAlwaysStaged: defines whether you can enable/disable your app’s content staging (i.e., selectable from the Publication screen). For example, setting this method to true automatically stages your app’s content. Users can no longer choose whether its content should be staged.

Other setter methods are available that control both Export/Import and Staging settings. You can reference them by visiting the Understanding the PortletDataHandler Interface section.

You can also control whether your app is enabled on the Staged Content screen by adding this method to your portlet data handler:

public boolean isConfigurationEnabled() {
    return false;

When this is set to false, your app is disabled on the Staged Content screen. This is set to true by default.

Figure 1: There are many apps available to select from the Staged Content screen.

Figure 1: There are many apps available to select from the Staged Content screen.

The majority of Staging-specific configurations are completed in a portlet data handler. The staged model data handler does come into play when you want to filter for certain staging processes/states. You’ll learn about this next.

Filtering Staging-Specific Processes and States

You can filter for certain staging-specific processes/states and complete actions based on the returned status. You can do this by leveraging the following classes from a staged model data handler:

The ExportImportThreadLocal class provides boolean methods that return whether a specific process is in progress. Use this to check for events affecting the entire site. For example, you can check if the following processes are in progress:

  • Local Staging
  • Remote Staging
  • Layout Validation
  • Portlet Staging
  • etc.

The StagingGroupHelper interface provides utility methods that return the staging state in your app. This is intended to check for events only affecting your app. For example, you can check if your app is in these states:

  • Resides in Local Staging group
  • Resides in Remote Live group
  • Is a staged portlet
  • etc.

A real example filtering for a staging process and state can be found in the AssetListEntryStagedModelDataHandler class:

if ((assetRendererFactory != null) &&
    ExportImportThreadLocal.isStagingInProcess() &&
        assetRendererFactory.getPortletId())) {


The staged model data handler uses the ExportImportThreadLocal.isStagingInProcess() method to verify that a staging process is running. It also checks whether the app is staged by executing !_stagingGroupHelper.isStagedPortlet(...).

Excellent! You can now filter for staging-specific processes and states.

« Initiating New Export/Import ProcessesIntroduction to Dependency Injection »
¿Fue útil este artículo?
Usuarios a los que les pareció útil: 0 de 0