Use the Folder Tree Performance Improvement

Introduction

Goal

Use the folder tree performance improvement that was introduced in Bloomreach Experience Manager 16.4.2 in order to optimize UI performance and user experience.

Background

Bloomreach Experience Manager's Content application displays the content structure in the repository as a folder tree. Loading the tree, and subtrees when opening folders, is known to be not performing well, because two levels of content are inspected to see whether a certain folder's subfolders are tree leaves or not.

To improve on that, the information whether a folder is a tree leaf or not is save as property on the folder itself.

How it works

All types of content folders (documents, gallery, assets) will support a new JCR property hippostd:hasfolders that reflects whether the folder contains one or more subfolders. The UI trees will read the new property and if it exists, skip iterating the subtree for subfolders detection, so will know instantly whether the folder is a leaf (not expandable) or not (expandable). This should greatly improve performance.

By default, the new 'hasFolders' property will be set by CMS folder worklow actions "add" and "remove". Moreover, the property will be re-evaluated by CMS folder worklow actions "reorder" and "rename" so CMS users have a way of correcting any wrong value, in case such occurs by non-CMS changes like console app or imports.

Optional Groovy script to initialize

An Groovy script named SetHasFoldersProperty is added to the Updater Editor perspective. It helps developers and/or administrators to set the 'hasFolders' property on existing content folder, after having deployed a new distribution to an existing repository. It can serve as well to reset the property when values have turned incorrect. See the script itself how it works.

Caveats: when to disable

Hidden folders

A possible known use case where iteration may still preferred over using the 'hasFolders' property is when some user groups do not have access to certain subfolders because of security domains. 

Given that:
1) the property is set using the user session for which some subfolders may be hidden 
2) the property is read using the user session which may be a different one than the one that set it

So, it can happen that the UI shows there are subfolders because the property indicates so but the user doesn't see them, or vice versa.

In those cases it can be considered to just disable the new feature, or, refrain from setting the property on those restricted (parent) folders, and also never add new folders to prevent the property being set automatically.

Old data type "directory"

The new 'hasfolders' flag applies to node type hippostd:folder (and subtypes) but not to the old data structure hippostd:directory. which used to represent a folder in the early days of Bloomreach Experience Manager. Should the existing repository contain this node type, there can be a UI glitch if its parent is a hippostd:folder, if that parent only has directories as children, and if its 'hasfolders' property is true.

Quite an edge case that can be mitigated by removing the property from that parent, or replacing the directory with a folder.

Configuration, how to disable

The behavior that folder workflow actions "add", "remove", "reorder" and "rename" will save the 'hasfolders' property is enabled out of the box. To disable it, developers can either set a system property or modify configuration in the repository in multiple locations.

Use a System Property

To disable the behavior overall, set system property repository.folderworkflow.set.hasfolders.property=false 

Change Repository Configuration

The default configuration to save the 'hasfolders' flag exists in all places below /hippo:configuration/hippo:workflows where class org.hippoecm.repository.standardworkflow.FolderWorkflowImpl has been configured to work on hippostd:folder type nodes, or on the subtypes for gallery and asset folders.

To disable the behavior on repository level, when wanting to do it more fine grained, or if a system property is not preferred, set the property set-hasfolders-property-behavior: false at:
 1. /hippo:configuration/hippo:workflows/embedded/folder-extended/hipposys:config
 2. /hippo:configuration/hippo:workflows/embedded/folder/hipposys:config
 3. /hippo:configuration/hippo:workflows/embedded/gallery/hipposys:config
 4. /hippo:configuration/hippo:workflows/internal/folder/hipposys:config
 5. /hippo:configuration/hippo:workflows/shortcuts/folder/hipposys:config
 6. /hippo:configuration/hippo:workflows/subsite/folder/hipposys:config
 7. /hippo:configuration/hippo:workflows/threepane/asset-gallery/hipposys:config
 8. /hippo:configuration/hippo:workflows/threepane/image-gallery/hipposys:config
 9. /hippo:configuration/hippo:workflows/threepane/folder-permissions/hipposys:config
10. /hippo:configuration/hippo:workflows/threepane/folder-extended/hipposys:config
11. /hippo:configuration/hippo:workflows/threepane/folder/hipposys:config
12. /hippo:configuration/hippo:workflows/threepane/generic-gallery/hipposys:config
13. /hippo:configuration/hippo:workflows/translation-internal/folder/hipposys:config

Custom FolderWorkflowImpl configurations

If a custom configuration exists in the implementation project on the class org.hippoecm.repository.standardworkflow.FolderWorkflowImpl, and similar behavior is wanted as the default, add this boolean needs to be added to the configuration subnode.

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

For reference, check one of the hipposys:config nodes listed above.