[PAGES-1052] Make it possible to retrieve subpages in the norsu delivery endpoint Created: 17/Feb/23  Updated: 24/Apr/23  Resolved: 24/Apr/23

Status: Closed
Project: Magnolia pages module
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Robert Šiška Assignee: Christopher Zimmermann
Resolution: Outdated Votes: 0
Labels: migration-jcr-to-norsu
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
relation
supersession
is superseded by MGNLREST-678 Support Norsu Content Store to genera... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
PAGES-1053 Implementation Sub-task In Progress Robert Šiška  
PAGES-1054 Review Sub-task To Do  
PAGES-1055 Pre-Integration QA Sub-task To Do  
PAGES-1056 QA Sub-task To Do  
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: SaaS Migration - DevX
Sprint: DevX 32
Story Points: 3
Team: DeveloperX

 Description   

Note

I split the "Filter out unwanted content from a Norsu node" part into this ticket: 

https://jira.magnolia-cms.com/browse/PAGES-1113

Original Description

For the purpose of navigation components, we need a way to retrieve subpages through the delivery endpoint.

In JCR, we can define an endpoint that only returns child nodes with a specific type. E.g. to get only subpages to build a navigation component, we define:

class: info.magnolia.rest.delivery.jcr.v2.JcrDeliveryEndpointDefinition
workspace: website
depth: 1
childNodeTypes: # defaults to mgnl:contentNode, returning only areas and components
  - mgnl:page 

Norsu rest endpoint should probably have analogous functionality, so we can avoid client-side workarounds like this.



 Comments   
Comment by Dominik Maslanka [ 22/Feb/23 ]

Hey rsiska , thanks for raising this ticket - it in the fetching sub-pages. Is there any extended need of a particular order/ structure that could be related to its navigation of it? cc: czimmermann 

Comment by Christopher Zimmermann [ 27/Feb/23 ]

rsiska just to confirm.. So the norsu REST API will have the same configuration as the JCR one did, right?

Comment by Robert Šiška [ 02/Mar/23 ]

After diving more into the code, it turns out that bringing back the support for nodeTypes and childNodeTypes properties is not feasible with our norsu endpoint implementation and with the way the content is stored (it would require major reworking of the whole endpoint logic).

These properties made sense in JCR and it gave users more power, but it was actually rarely used - the only use-case we identified is navigation component, which can be also achieved with @nodes suffix (and optionally limiting the depth). The suffix works very similarly in both JCR and norsu and the only downside is that the responses are bigger in norsu, which shouldn't be a problem when the responses are cached.

So my suggestion is to suggest using @nodes as the best-practice and deprecate nodeType-filtering properties altogether (and close this ticket as won't do).

Comment by Christopher Zimmermann [ 06/Mar/23 ]

I think there are 3 issues:

1. Getting a tree of content.

JCR can return a tree. I ask for an item and its children down to a certain depth. So with one call to "pagenav" endpoint I get the information that I need in a structure that makes sense.

Norsu does not return a tree. It returns flat lists. Each item has a path poperty, so the frontend can reassemble the tree datastructure if needed. Its just extra work.

 

2. The meaning of "depth" has sort of changed in Norsu.

In JCR, depth was how deep of children should be returned FOR EACH RETURNED ITEM.

In Norsu, depth has an impact on WHICH ITEMS ARE RETURNED for the @nodes and query, but has no effect when doing a ReadNode.

This is confusing for a developer (although I see that it helps to enable the usecases devs still need to implement)

 

3. Complete page (with areas and components) is always returned, which can be a lot of unneeded content. Its ok if its just a few pages, but would be bad for sitemap purpose for example.

But we can solve this by introducing some features to specify which props to return - or a special parameter to exclude "area and component" from page.

 


Just summarizing how I see status, have to still think and discuss whaat to do.

Comment by Robert Šiška [ 06/Mar/23 ]

I think it all stems from how we treat areas and components as kind of second-class citizens. We store/treat the whole page as one node and all its areas and components as its content. That's why it's not possible with the current API to retrieve e.g. only a single area or component, or retrieve a page without areas and components.

Comment by Robert Šiška [ 07/Mar/23 ]

Follow-up discussion will be needed. Here are the concerns identified during the work on this ticket: https://wiki.magnolia-cms.com/display/DEVINT/Norsu+Content+Delivery+concerns

 

I'd suggest we either close this ticket until we have a decision, or move it back to discovery or ready to discovery.

Comment by Christopher Zimmermann [ 24/Apr/23 ]

Work on this ticket is happening in MGNLREST-678

Generated at Mon Feb 12 06:24:39 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.