CRISTAL-226: Breadcrumb for Nextcloud

[pjeanjean]

Jira URL

https://jira.xwiki.org/browse/CRISTAL-226

Changes

Description

• Add a page hierarchy resolver for Nextcloud
• Factorize FileSystemPageHierarchyResolver and NextcloudPageHierarchyResolver through getPageHierarchyFromPath()
• Fix small issues with the Nextcloud backend

Clarifications

Considering the page ids with the Nextcloud backends are simple paths, we can reuse the same logic for the breadcrumb as for the FileSystem backend.

Screenshots & Video

Executed Tests

The breadcumb was tested manually with a local Nextcloud instance.

Expected merging strategy

• Prefers squash: Yes
• Backport on branches:
  • N/A

[pjeanjean]

This should be cleaner now.

Note: I do not fully understand what the goal was with this process, but sometimes (only with the XWiki backend I believe) this loadPage() was called after the content had been set (and other times before), leading to a race condition (that I could only reproduce with the Shoelace ds) where the content would be a 404 because getPageFromHash() returns an URI encoded id.

Apparently, Manuel planned to deprecate getPageFromHash() at some point, so my change is just a stopgap until either he comes back or I finally understand what this does.

[mflorea]

Hi @pjeanjean , it's still not clear to me when should the page id be decoded / encoded and when not. Since you worked on this, maybe you can document somewhere, either in code, or on https://cristal.xwiki.org/ what is the page id for each backend we support (its format, encoding, examples).

Then, the way I see it, the page id is specified in the Cristal page URL, so when accessing a Cristal page, we have to extract the page id from the URL and then pass this id to various API, such as the storage API to get the content of the page and its metadata. So there must be a way to encode and decode the page id in the Cristal URL, which is independent of the used backend. Ideally this should be encapsulated in a single component / API (resolve page id from URL and get page URL from page id). Do you know if we have this?

Then, with the page id extracted from the URL, each backend is dealing with it differently, because:

• for some backends the page id is a file path (file system and Nextcloud?)
• for others, like XWiki, it's a serialized entity reference

But they shouldn't have to decode / encode the full page id. They may have to decode / encode some parts of it, depending on the id format, but not the entire page id. Am I right?