We are working with the SPA++ resourceapi. I was wondering why the links to the content items themselves (the self links) are not in the context of the current sitemapitem.
The links are rendered in the HippoBeanSerializer and this uses the following createLink call: requestContext.getHstLinkCreator().create(node, mount)
why is this not the following call? requestContext.getHstLinkCreator().create(hippoBean.getNode(), requestContext)
The issue we run into is that for instance is that linkedBeans in a certain document for which the links are rendered in the frontend based on the selflink always have the link to their canonical and do no stay in the context of the site
E.g. there is a newsitemlist on a page /context and newsitems can be rendered either on /news/{item} or under /context/news/{item}
Because of the choice of creating a link on the mount instead of the requestContext the retrieved path (selflink) is always /news/{item}
Our fix would be to add either a correct context link in the bean of newsitem or in the linkedBeansList retrieved; creating a list which has objects with the correct link and the bean itself, but both workarounds feel a bit iffy.
I was wondering why the choice was made to not create a contextual link in the serializer and if it can be changed to be a contextual link? Or if there is a cleaner solution than our proposed workarounds.
Do you mean a content item under “content” has only “self” link in “_links”?
In that, it should have “site” link [1], which represents a normal site link, not the resource API link (self), no?
Yes I meant the site link under content. As its a link to the bean itself I dubbed it selflink
But the question is why is this link not context related but always the ‘canonical’ or shortest path from the root?
HstLinkCreator.create(node, mount) versus HstLinkCreator.create(node, requestContext)
I guess it was because it cannot use requestContext when making a link against the site mount when the current request mount is not the site mount but its child, the pagemodel api mount.
I guess it was because it cannot use requestContext when making a link against the site mount when the current request mount is not the site mount but its child, the pagemodel api mount.
That seems to work just fine as the pagemodelapi mount uses the same sitemap as the normal mount (at least in our case) and the links are relative and dont have any specific mount information attached.
You now loose all the context creation in the links which is normally really nice from hippo to be able to correctly render the same content in different places.
But I guess we will just have to create our own links instead of using the site.link in the meta.
Good point! As Page Model JSON API is not supposed to be configured with a different sitemap and channel configuration, but to complement its parent channel/mount in principle, your case seems rather generic to me. Thanks for sharing your insights. I think you can file a HSTWO JIRA ticket to fix this.
As sitemap and linking is @ard.schrijvers’s expertise, I’d like him to chime in or look into it as well.
I created a ticket. I had to safe it while I was not finished with giving all the feedback so some of the information sits in the comments as Im not allowed to edit the created ticket.
If certain information is missing please let me know.
