[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: |
|
||||||||||||
| 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: | |||||||||||||
| 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
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: If I wanna inheritance and autogenerate I call: If I wanna resolve dam params I call: 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. |