[MGNLREST-719] Prepare out of the box pages endpoint with all predefined configured property Created: 01/Jun/23  Updated: 23/Oct/23

Status: Open
Project: Magnolia REST Framework
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Oanh Thai Hoang Assignee: Christopher Zimmermann
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLFE-467 Update template and rest endpoint of ... Closed
relates to MGNLREST-732 Tune default configuration of jcrPage... Closed
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: Headless Backlog
Team: DeveloperX

 Description   

 

We can provide a default /.rest/pages/v2 in light dev resource in https://git.magnolia-cms.com/projects/MODULES/repos/pages/browse/magnolia-spa-rendering/src/main/resources/spa-rendering/restEndpoints

 

for use without config anything

 

$type: jcrPagesDeliveryEndpoint_v2
workspace: website
systemProperties:
  - mgnl:template
depth: 100
nodeTypes:
  - mgnl:page
  - mgnl:area
  - mgnl:component
childNodeTypes:
  - mgnl:area
  - mgnl:component
personalized: true 
inheritanceComponent: false
autogenerateComponent: false 

 

 

 

We have to propose another 2 new property config here (inheritanceComponent and autogenerateComponent ) for jcrPagesDeliveryEndpoint_v2 configuration. So user can config them to true if they want to support, but default both of them are false 

 

Update: A part of this ticket has been done. Default properties has been set to jcrPagesDeliveryEndpoint_v2 by default

See https://git.magnolia-cms.com/projects/MODULES/repos/pages/pull-requests/578/overview

From 6.2.35: User can define page endpoint simply like below. Note: You still have to define resolver by your own

 

$type: jcrPagesDeliveryEndpoint_v2
bypassWorkspaceAcls: true

references:
  - name: assetReference
    propertyName: image
    referenceResolver:
      class: info.magnolia.rest.reference.dam.AssetReferenceResolverDefinition 


 Comments   
Comment by Christopher Zimmermann [ 01/Jun/23 ]

Exciting proposal! I will check with a few people but I like the idea a lot.

Why would the inheritance and autogenerate be false by default?

Comment by Oanh Thai Hoang [ 02/Jun/23 ]

Hi czimmermann , this proposal from bstaryga instead but I do love prepare a default pages endpoint so it will be improved user experience for sure. 

And

Why would the inheritance and autogenerate be false by default?

To me: inheritance and autogenerate be false by default to increase user experience because if user don't have inheritance and autogeneration but our page rest point always deeply check template from each of areas. It may takes time. But I can do a test to compare time execution with a huge pages node if we intend to enable them as true

Comment by Christopher Zimmermann [ 02/Jun/23 ]

I have a concern. I agree that this would be a big plus for developers who are just getting going and would simpify our basic demo projects.  But I think on most projects developers will want to add ReferenceResolvers, especially for assets. So I think that on most projects developer will either need to decorate the default endpoint, (which is OK but slightly complicated) or they will need to make their own endpoint, page_myproject.yaml

What do you think oanh.thai and bstaryga ? (Which othere services devs would have an opinion? maybe vsakaria and chris.jennings and srhodes )

(I want to change how we do reference resolving - putting it in the component instead of the endpoint definition.. but thats in the future.)

Comment by Christopher Zimmermann [ 02/Jun/23 ]

oanh.thai a speed test would be useful to know, yes please.

Comment by Vishal Sakaria [ 02/Jun/23 ]

I'm not quite getting with that thread about but if it's about simple flying reference resolvers then I can see the benefit of that short-term. But I do think the ability to have full configuration is also important. So both would be my suggestion

Comment by Bartosz Staryga [ 02/Jun/23 ]

The developer required configuration should be as minimal and as easy to add as possible.

As many things as do not impact too much performance should be enabled out of the box.

Decorations are bit cumbersome I would suggest we consider enabling features/resolvers on the fly with url parameters.

If I wanna default behavior I call:
/.rest/pages/v2/<endpointPath>
If I wanna inheritance enabled I call:
/.rest/pages/v2/<endpointPath>?inheritance=true{}

If I wanna inheritance and autogenerate I call:
/.rest/pages/v2/<endpointPath>?inheritance=true&autogenerate=true

If I wanna resolve dam params I call:
/.rest/pages/v2/<endpointPath>?damResolver=param1,param2,param3

Template annotations added in response -> param foo set to true

...and so on and so forth.

Once we have such a endpoint we could test if e.g inheritance as true really impacts the speed or we should make it default true. 

TBH Magnolia could come with one endpoint to serve them all so we could minimize the need to create endpoint via LM to absolute minimum.

Something: /.rest/delivery/<workspace>/<endpointPath>?parm1=true...paramX=true

Query params to enable disable certain functionalities.

Comment by Christopher Zimmermann [ 13/Jun/23 ]

For the record, I support this initiative. But based on the above discussion I believe it needs more discovery and shaping work, including a reworking of how reference resolvers work.

Generated at Mon Feb 12 07:02:31 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.