Break /children REST API to follow default hierarchy mode

Development
1

Hello everyone,

we recently noticed while working on the pinned child pages feature that the /children REST resources is currently still using by default the old parent/child relationship by default.
@mflorea improved the API to allow specifying a parameter to use the reference (nested page) relation which is the default in XWiki since 7.2.

Now IMO the /children REST resources should always follow the configuration core.hierarchyMode specified in xwiki.properties and which uses reference by default. I don’t see a good reason to keep having this resource returning by default answers using a mode that is long deprecated now.

So my proposal here is to:

  1. Break the REST API behaviour to always rely on the core.hierarchyMode configuration to know which mode to use
  2. Ensure to provide a parameter allowing to force the model to use either parent/child or nested, without relying on core.hierarchyMode: any extension relying on the current behaviour could modify without much change the URLs to use this parameter.

I tried to search for /children in xwiki-contrib: we have a few hits but not that much: Code search results · GitHub

I propose to perform those changes only in master.
I’m opening this vote for 2 weeks, until 10th June 2024.

Here’s my +1.

2

We already have this with the new (query string) parameter added in 16.4.0RC1. What’s missing is to fallback on the core.hierarchyMode configuration when that parameter is not specified (which would basically mean using the nested pages hierarchy mode by default).

+1

Thanks,
Marius

3

+1 thanks

4

+1, thank you!

5

+1

6

+1

Note that, for consistency, there might be other parts of the REST API not following the hierarchy mode that might need fixing, like e.g. xwiki-platform/xwiki-platform-core/xwiki-platform-rest/xwiki-platform-rest-server/src/main/java/org/xwiki/rest/internal/ModelFactory.java at 8a7283f5dfe0a84388e1ec8e7324fe153327fcb9 · xwiki/xwiki-platform · GitHub

7

Right this is apparently used to set the hierarchy node of a page.

8

btw I noticed that we use a condition doc.getChildren().isEmpty() to display or not the the children relation in the page results: we might have an inconsistency if we applied the proposed change and keep that condition, as /children call might come from the nested page while the relation wouldn’t be displayed because of the check performed with parent/child relation.
It means that we’d need to allow using the forcing parameter not only for /children resource, but also for /page resource.

9

Thanks for the votes and feedbacks. I’m closing this vote as accepted with 6 +1. I opened Loading... for improving it.