[PAGES-1153] Component Inheritance with Visual SPA Editor Created: 18/Aug/20 Updated: 14/Jun/23 Resolved: 19/May/23 |
|
| Status: | Closed |
| Project: | Magnolia pages module |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.3.0, 6.2.28 |
| Type: | Story | Priority: | Major |
| Reporter: | Christopher Zimmermann | Assignee: | Oanh Thai Hoang |
| Resolution: | Fixed | Votes: | 7 |
| Labels: | None | ||
| Σ Remaining Estimate: | Not Specified | Remaining Estimate: | Not Specified |
| Σ Time Spent: | 7d 1.5h | Time Spent: | 5d 3.5h |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Sub-Tasks: |
|
||||||||||||||||||||||||||||||||||||||||
| Template: | |||||||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||||||
| Task DoD: |
[X]*
Doc/release notes changes? Comment present?
[X]*
Downstream builds green?
[X]*
Solution information and context easily available?
[X]*
Tests
[X]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||||||
| Epic Link: | SPA Editor Backlog | ||||||||||||||||||||||||||||||||||||||||
| Sprint: | DevX 37, DevX 38 | ||||||||||||||||||||||||||||||||||||||||
| Story Points: | 5 | ||||||||||||||||||||||||||||||||||||||||
| Team: | |||||||||||||||||||||||||||||||||||||||||
| Work Started: | |||||||||||||||||||||||||||||||||||||||||
| Approved: |
Yes
|
||||||||||||||||||||||||||||||||||||||||
| Description |
|
As a developer I want to use magnolias 'Component Inheritance' feature when I use the Visual SPA Editor (SPA Renderer and frontend frameworks and REST endpoints) so that I can provide a very comfortable author experience for things like footers, headers and sidebars. Acceptance Criteria
Context Component Inheritance is a popular feature in Magnolia templating. It allows authors to configure componets on a top page, and then all of the subpages automatically get that same configuration. It is typically used for things like headers, footers and "extra" or "sidebar" content. There are workarounds, such as managing that content to be shared across multiple pages in its own unique page, or in a separate app. But the authoring experience is not as good, its more complicated. It would be better to enable this useful features for SPA as well as freemarker templating. Workaround Use inheritance without rest inheritance in SPA: For Discovery phase:
|
| Comments |
| Comment by Simon Tourville [ 21/Aug/20 ] |
|
This issue is at least present in version 6.2. |
| Comment by Marc Johnen [ 08/Jan/21 ] |
|
Is there a time frame for this? I wouldn't have expected this to be missing in the initial release. |
| Comment by Christopher Zimmermann [ 11/Jan/21 ] |
|
No concrete timeframe yet. |
| Comment by Marc Johnen [ 11/Jan/21 ] |
|
My current solution is to hardcode this in the page.js //get header from homepage const headerRes = await fetch(baseUrl + homePage); let header = await headerRes.json(); header = header["header"]; //add it to current page page["header"] = header; As we are using a Next server, a second request per page is ok.
|
| Comment by Simon Tourville [ 14/Jan/21 ] |
|
Interesting solution but the requires an extra HTTP request which we would be happy to get rid of, ideally. |
| Comment by Bartosz Staryga [ 25/Mar/21 ] |
|
slutz any update/eta for adding inheritance to Delivery Endpoints? We get questions on regular basis regarding this |
| Comment by Christopher Zimmermann [ 31/Mar/21 ] |
|
Marking as related to |
| Comment by Bartosz Staryga [ 29/Nov/21 ] |
|
Workaround to use inheritance without rest inheritance in SPA: |
| Comment by Mykola [ 17/Feb/22 ] |
|
worth noticing, that inheritance not always is enabled at the root page level, it can be any nested page |
| Comment by Mykola [ 17/Feb/22 ] |
|
maybe some kind of a resolver (like AssetReferenceResolverDefinition) would work? |
| Comment by Canh Nguyen [ 18/Apr/23 ] |
|
The Delivery Endpoint is designed to serve data generally for pages and other content types. It's not working like a rendering engine that mixes content and template definitions. There are some solutions could be implemented to support this feature:
|
| Comment by Christopher Zimmermann [ 18/Apr/23 ] |
|
Based on internal discussion, lets go with 3rd proposed solution:
Re: "return template annotations corresponding to each area/component " |
| Comment by Marc Johnen [ 18/Apr/23 ] |
|
As I understand, you want tie the generation of JSON to pages and components similar to Excuse my honest opinion: the current headless implementation has a bad architecture and is This is a list of the most frequent issues I face using headless:
I'm sorry for all this negativity, but magnolia headless is in dire need improvement. |
| Comment by Mykola [ 18/Apr/23 ] |
|
I believe that there is a reasoning behind that choice, but still.. my first reaction is that yet another endpoint would bloat SPA side... but maybe I'm wrong. We even didn't have any proof-of-concept on this stage. Maybe it won't be a problem. I hope it would not be a separate endpoints like /.rest/delivery/pages for regular content and /.rest/pagesWithInheritance with inheritance |
| Comment by Mykola [ 18/Apr/23 ] |
|
@marc.johnen I'm also experience some of difficulties mentioned by you
|
| Comment by Christopher Zimmermann [ 25/Apr/23 ] |
|
Hi marc.johnen thank you for your detailed input. It's appreciated and we do consider it. There are a number of related tickets, but I have created one specifically for the namespace problems of the referenceResolver. I also created a wiki page with some ideas - maybe you can have a look and see what you think and possibly add more ideas. Feel free to edit the page. (You too NDQ !) |