[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: |
|
|||||||||||||||||||||||||
| Sub-Tasks: |
|
|||||||||||||||||||||||||
| 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: | ||||||||||||||||||||||||||
| 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 |