Folder Tree Performance Improvement

Info: This feature is available starting from brXM 16.4.2.

Overview

This page describes how to use the folder tree performance improvement introduced in brXM 16.4.2. The improvement optimizes the performance of the Content application’s folder tree in the user interface.

Background

The Content application in Bloomreach Content displays repository content as a folder tree. Previously, loading the folder tree and its subtrees required inspecting two levels of content to determine whether a folder’s subfolders were leaves. This approach caused performance issues.

To address this, Bloomreach Content now stores information about whether a folder is a tree leaf as a property on the folder node itself.

How the Improvement Works

All content folder types—documents, gallery, and assets—now support a JCR property named hippostd:hasfolders. This property indicates whether a folder contains one or more subfolders.

When the UI renders the folder tree, it reads the hippostd:hasfolders property. If the property exists, the UI does not need to iterate through the subtree to detect subfolders. Instead, it can immediately determine if the folder is expandable (has subfolders) or a leaf (no subfolders). This change significantly improves folder tree loading performance.

The hippostd:hasfolders property is set automatically by CMS folder workflow actions:

add
remove

Additionally, the property is re-evaluated during the following actions:

reorder
rename

This ensures that the property remains accurate, even if changes occur outside the CMS (for example, via the console application or imports).

Initializing the Property with a Groovy Script

A Groovy script named SetHasFoldersProperty is available in the Updater Editor perspective. Use this script to set the hippostd:hasfolders property on existing content folders after deploying a new distribution to an existing repository. The script can also reset the property if values become incorrect. Review the script for implementation details.

Limitations and When to Disable the Feature

Hidden Folders and Security Domains

If some user groups do not have access to certain subfolders due to security domains, the following applies:

The hippostd:hasfolders property is set using the current user session, which may not have visibility into all subfolders.
The property is read using the session of the current user, which may differ from the session that set the property.

As a result, the UI may indicate that subfolders exist when the user cannot see them, or the opposite. In these scenarios, consider disabling the feature or avoid setting the property on restricted parent folders. Also, prevent the addition of new folders in these areas to avoid automatic property updates.

Legacy Node Type: `hippostd:directory`

The hippostd:hasfolders property applies to nodes of type hippostd:folder and its subtypes. It does not apply to the legacy hippostd:directory type, which was used in earlier versions of Bloomreach Content. If your repository contains hippostd:directory nodes and their parent is a hippostd:folder with hippostd:hasfolders set to true, the UI may display incorrect folder states.

To resolve this, either remove the property from the parent folder or replace the directory node with a folder node.

Configuration: Disabling the Feature

By default, the folder workflow actions add, remove, reorder, and rename update the hippostd:hasfolders property. You can disable this behavior globally or for specific workflows.

Disable Using a System Property

To disable the feature for the entire repository, set the following system property:

repository.folderworkflow.set.hasfolders.property=false

Disable Using Repository Configuration

The default configuration for saving the hippostd:hasfolders property exists in multiple locations under /hippo:configuration/hippo:workflows, where the class org.hippoecm.repository.standardworkflow.FolderWorkflowImpl is configured for hippostd:folder nodes and its subtypes (gallery and asset folders).

To disable the feature at the repository level or for specific workflows, set the following property:

set-hasfolders-property-behavior: false

Apply this property to any of the following configuration nodes:

/hippo:configuration/hippo:workflows/embedded/folder-extended/hipposys:config
/hippo:configuration/hippo:workflows/embedded/folder/hipposys:config
/hippo:configuration/hippo:workflows/embedded/gallery/hipposys:config
/hippo:configuration/hippo:workflows/internal/folder/hipposys:config
/hippo:configuration/hippo:workflows/shortcuts/folder/hipposys:config
/hippo:configuration/hippo:workflows/subsite/folder/hipposys:config
/hippo:configuration/hippo:workflows/threepane/asset-gallery/hipposys:config
/hippo:configuration/hippo:workflows/threepane/image-gallery/hipposys:config
/hippo:configuration/hippo:workflows/threepane/folder-permissions/hipposys:config
/hippo:configuration/hippo:workflows/threepane/folder-extended/hipposys:config
/hippo:configuration/hippo:workflows/threepane/folder/hipposys:config
/hippo:configuration/hippo:workflows/threepane/generic-gallery/hipposys:config
/hippo:configuration/hippo:workflows/translation-internal/folder/hipposys:config

Custom FolderWorkflowImpl Configurations

If your implementation project defines a custom configuration for org.hippoecm.repository.standardworkflow.FolderWorkflowImpl and you want to enable or disable this behavior, add the following boolean property to the relevant configuration subnode:

/hippo:configuration/hippo:workflows/<category>/<workflow>/hipposys:config: 
  set-hasfolders-property-behavior: true

Refer to one of the hipposys:config nodes listed above for examples.