[MAGNOLIA-9081] Alternative flat content app experience, and implicit JCR sharding Created: 05/Sep/23  Updated: 07/Dec/23

Status: Open
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Epic Priority: Neutral
Reporter: Mikaël Geljić Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: dx-core-6.3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Epic Name: Flat content app experience
Acceptance criteria:
Empty
Date of First Response:

 Description   

Editing large-scale content within Magnolia usually comes through content-apps and content-types. Typically, website pages don't grow as much. Few dynamic pages rather link to products/types via URI2RepositoryMapping (headful) or via delivery API (headless).

  • For content-types, a tree usually doesn't even make much sense.
  • All content in the workspace has the same flat model.
  • Sometimes editors use folders, but past a certain scale, this becomes irrelevant or worse, gets in the way (click-intensive to expand 2–3 levels before accessing the desired piece of content).
    Then editors resort to search in first intention.

(Additionally, cases such as 1-directed hierarchical node-types, e.g. company » department » employee) are not supported by content-types, and in fact not so common).

Workarounds

  • Many customers resort to hierarchy maintained "by hand" by editors, which is neither convenient for them, nor very robust.
  • Using search via column filters in first intention, when opening the app.

Background

The two main reasons we offer a tree-like experience are:

  • Jackrabbit notoriously struggles with 1000+ nodes on same level
  • That's how the default "app template" is for content-types; a list view is provided, but only secondarily (one click too far away), and no easy way to turn off the tree view.

Proposal

Offer a flat content app experience, and hide the hierarchical sharding in JCR behind the scenes.

This involves several components and aspects:

  1. Alternative list view, most likely bespoke implementation using Vaadin's Grid in more opinionated ways. With less of the complex UI features incurring performance penalties, and maintainability overhead (column filters).
  2. Surfacing recent content relevant to current editor (Google Drive-like). For non-recent content, assume the Find bar is good enough at first. Querying all results and bulk-edits are also interesting, but only after we validate browsing performance.
  3. Data bindings & Save actions transparently writing to JCR according to the desired sharding strategy.

Implementation note

Jackrabbit offers some utilities for dealing with flat structures in the org.apache.jackrabbit.commons.flat package. The interfaces and classes in that package allow transparent mapping of flat structures to a node hierarchy. The default implementation is based on a BTree, which splits nodes on insertion when necessary. The focus of the utility is on sequential access rather than random access and searching.



 Comments   
Comment by Aleksandr Pchelintcev [ 18/Sep/23 ]

Another possibility to double check/verify is how the JCR's struggle with flat lists is related to the order support. I can't tell from the top of my head but my hunch is that we do enable orderable trait for the nodetypes/workspaces by default. If that's really the case - could we drop it by default and rather indeed rely on the approaches like surfacing the latest content or other optional ways of sorting the nodes?

Generated at Mon Feb 12 04:38:25 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.