This issue has been created
 
 
CLI / cid:jira-generated-image-avatar-2cc50843-b994-4c7e-8eb4-df23439b2794 CLI-14 Open

Simplify the synchronized file hierarchy

 
View issue   ยท   Add comment
 

Issue created

 
cid:jira-generated-image-avatar-adb1a8b7-08b4-4450-bc71-e244dedb1db8 slauriere created this issue on 30/Sep/24 16:19
 
Summary: Simplify the synchronized file hierarchy
Issue Type: cid:jira-generated-image-avatar-2cc50843-b994-4c7e-8eb4-df23439b2794 Improvement
Assignee: Unassigned
Created: 30/Sep/24 16:19
Priority: cid:jira-generated-image-static-major-97b649ab-fa7e-4ac0-aa3d-83691c2d2509 Major
Reporter: slauriere
Description:

The current folder structure of synchronized files mirrors the REST path structure.

This ticket is to explore potential simplifications of the folder hierarchy, particularly by possibly removing the folders pages, spaces, and WebHome. The goal is to make the folder tree easier to navigate.

Proposal:

|- wiki
  |- MySpace
    |- content
    |= class
    |= objects
    |= files
    |= MySubPage1
      |- content
      |= objects
      |= MySubSubPage
    |= MySubPageTerminal
      |- content
      |= objects
  |-MySpace2
  |- ...

In this structure, all pages would be represented as folders, including terminal ones, with the value of the terminal property stored within each folder. There are two downsides with this approach:

  • It does not allow out of the box for a terminal page to have the same name as a space
  • Nor does it allow spaces to be named "objects" or "attachments".

However:

  • We may consider that the advantage of providing a simple hierarchy outweighs the first limitation. In most cases, having terminal pages and spaces share the same name is undesirable as it introduces confusion for developers, users, and potentially even search engines. We could introduce special characters in folder names when the case arises.
  • Along the same, line, we could make the names "objects" and "files" configurable so that users would have the ability to name them as they wish to avoid collisions.

Adding also for the record that we should check how the XWiki PageReferences handle this scenario, since they allow to create references without the WebHome part as well.