Details
-
New Feature
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
0.5
-
Puma Sprint 227, Puma Sprint 228-SaaS BrX v0.2
Description
Motivation:
- The tree representation of the page model brings extra complexity to the SPA SDK. We have to implement DFS to avoid recursion. That requires a basic queue implementation, which may consume up to O(N) extra memory.
- The component update operation requires BFS implementation to find the right node. This may have some negative impact on performance when users are using the Visual Editor.
- The flattened structure will simplify dependency injection on the SPA SDK side. This will allow us to provide extra extensibility in the SPA SDK.
Currently, the PMA is something like this at this moment
{
id: ""
_meta {}
_ link {}
page {
"id": "123"
"components": [
"id":"123"
"components": [
"id":"123"
"models": "document":{
"$ref":"/content/u895fb1b6410d497298946b6a06d2b361"
},
"menu":{
"name":"main",
}
]
]
}
content {
"u895fb1b6410d497298946b6a06d2b361":{
"id":"895fb1b6-410d-4972-9894-6b6a06d2b361",
"_links":{
"site":{
"href":"/site/myapp",
"type":"internal"
}
},
}
}
where page contains components which can have content items which are serialized as $ref where they point to a content item below content
The $ref to documents works well for frontend developers as well as for graphQL. However, that should be done for any 'entity' object, where for example entities are objects like
- component
- menu
- pageable
- taxonomy (??)
- content blocks (???)
- { downstream project entities}
Taking this into account, the following PMA output is most likely much easier for frontend devs:
{
meta: { version: 2.0 },
links: { ... },
page: {
"uuid": {
type: "component",
name: "blabla",
models: [
{ $ref: "page/uuid4" }
],
children: [
{ $ref: "page/uuid2" }
]
},
"uuid2": {
type: "container",
models: [
{ $ref: "page/uuid3" }
]
},
"uuid3": {
type: "content",
content: { value: "<html>" },
}
"uuid4": {
type: "menu",
}
"uuid5": {
type: "pageable",
}
}
}
As part of this newly formatted PMA output, we also need to support downstream projects to register 'entity' objects, which should get serialized as 'entity (thus on root level). For example, an ecommerce integration should be able to insert Product to be an entity, meaning that if an HstComponent has the Product (or subclass thereof) object as model object, it should serialize that into a separate page/uuid object.
Attachments
Issue Links
- waits for
-
-
- Closed
-
-
HSTTWO-4734 Replace the Jackson Serialization Mixin logic to suppress certain properties from HippoBean objects to be serialized
-
- Closed
-