[MGNLREST-216] Customize content format and perform business logic on server Created: 18/Nov/19  Updated: 25/Apr/23

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

Type: Story Priority: Major
Reporter: Christopher Zimmermann Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File EventDetails.java     Java Source File EventDetailsResolver.java     Java Source File EventDetailsResolverDefinition.java     Java Source File EventDetailsWriter.java     File pages_v1.yaml    
Issue Links:
Relates
relates to MGNLREST-329 ReferenceResolver should provide acce... Accepted
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)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:

 Description   

User story:

As a SPA developer, I want to get content in the correct format, so that I can use the content write away in my components without changing the component or massaging the data.

As a Magnolia developer, I want to run model code and return results of this code to the frontend components, so that I can solve more complex customer requirements such as serverside calculations.

Notes:

See: SPA - How to match content to API of JS components

 

Acceptance criteria:

  • Control the 'format' of the content that is passed to a frontend component, such as property names,  arrays vs maps, heirarchies.
  • Run models and deliver content from them.

Notes:

If we added GraphQL support - it would be likely be a little file living next to each component to specify the props to get and their shape. Therefore, without GraphQL an alternative would be to support a "JSON transformer file", or a component model, which would specify or remap the default content, and supply it as a new JSON format. Possibly this could also be supplied as an FTL file to provide "templating the JSON response".



 Comments   
Comment by Marc Johnen [ 05/Jan/21 ]

I think this is also related to MGNLREST-188.

The way I see it the resolvers of the JcrDeliveryEndpoint are not powerful enough. Minimum they should have access to the node a property is coming from. 

Comment by Christopher Zimmermann [ 05/Jan/21 ]

marc.johnen could you provide any concrete examples of what you would want to be able to get and why? What do you mean by "access to the node", can you not already get all the properties you want to get from that node when it is resolved? Or are some not available?

Comment by Marc Johnen [ 07/Jan/21 ]

I'm currently migrating a project with a custom implementation of a react frontend to the extended spa editor.
Out of the box the JcrDeliveryEndpoint can't expose business logic, but we need information like event dates,
participants, free spaces and so on.
I had to add a dummy property in a dialog and write a ReferenceResolver for it. But the resolver only gets
the property value passed on and not the node the property is coming from. That's why I get the component node via
the current uri of the aggregation state to access the needed data.
Also the resolver doesn't like a map or complex json array as return value (quotes will be escaped).
If I return a custom dto, generation of json will just stop after processing that resolver without
any message. So I added a custom MessageBodyWriter, which only if it's in a info.magnolia package
(I would say MGNLREST-229 has not been resolved) and also needs an entry in the javax.ws.rs.ext.Providers.
It may be that this solution is unnecessary complicated due to my lack of understanding, but it is the best
I could come up with.
A mechanism is needed to easily add business logic to a specific place in the json.
I would say that even though I like the new spa module and it's clearly going in the rigth direction,
it is only really suitable for quite simple websites so far.

Also the standard structure nodes are mapped is difficult to handle in react, I guess an array would be more suitable.

"00": { ... }, 
"01": { ... }, 
"@nodes": [ "00", "01" ]

I would also wish for some mechanism to handle i18n in json (see https://groups.google.com/a/magnolia-cms.com/g/user-list/c/sTtp8N7R2Hw).
In a custom endpoint I often used i18n properties to create values in json, but I have no clear idea how to best integrate such a thing.

The link above "SPA - How to match content to API of JS components" does not work btw..
I will attach an example.

Comment by Marc Johnen [ 25/Jan/21 ]

Also the filter of the JCRDeliveryEndpoint quickly reaches it's limit. See https://groups.google.com/a/magnolia-cms.com/g/user-list/c/7-FLrvKnRyE/m/wbV0xy5fDAAJ
So GraphQL sound very interesting.

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