[MGNLCT-137] Apps can have a hierarchy of types, each powered by a content type Created: 28/Nov/19 Updated: 24/Jan/23 |
|
| Status: | Accepted |
| Project: | Content Types |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Neutral |
| Reporter: | Vivian Steller | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 11 |
| Labels: | collector-0cf1239d | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | |||
| 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: | Content Types phase 2 | ||||||||||||||||||||||||||||||||||||
| Description |
|
What we'd need is support for multiple node types within the same app, supporting custom dialogs per node type (natively) Example use case:
+ week
+ category
+ offer
We want to create a hiearchical instead of a flat content app. At the root level "week" components shall be available, within these "category" components and within these in turn "offer" components (and potentially other ones on the same level). I'd be happy to discuss possible solutions / enhancements to the current *Content Types* concept. |
| Comments |
| Comment by Christopher Zimmermann [ 28/Jan/21 ] |
|
There are different ways we could approach this requirement. I propose that the requirement is having an app which supports multiple node types in the browser. The question is how should the content-type concept be connected to this? For example.. is it one content type definition with multiple "sub model" types? Or is it rather multiple content types, and the app definition then brings them together in one app? |
| Comment by Vivian Steller [ 29/Jan/21 ] |
|
Hi Topher, happy to see progress here!
I'd prefer different content type definitions, not sub models. As these could potentially be reused across apps. Further, I would connect them via the app definition but rather link/reference them in the content type definitions itself. Similar to what the node type definitions do, basically. They define what child node types are availabe, with what cardinality etc. Linking them via the app definition would be a step backward again: To me, app definition is (kind of) part of the View layer, as it allows how to visualise/render a content type. The content type definition is clearly part of the Model layer. Linking two models via the app definition would break this layer concept and would fall back to what we had in the past: implicit model definition in the view layer (dialog defnition). Does this make sense? |
| Comment by Christopher Zimmermann [ 08/Mar/21 ] |
|
Yes vivi makes sense, thanks for your input. (I read your comment back when you posted it - just late response here. |
| Comment by Christopher Zimmermann [ 08/Mar/21 ] |
|
Workaround is to create an app with a full app definition instead of using a contentType or set of contenttypes. |
| Comment by Viet Nguyen [ 04/Jun/21 ] |
|
Hello czimmermann and vivi, I would suggest below improvement: 1. Content type is "clearly part of the Model layer" which is clear.
The missing part here is the support of easily configure a custom app with reference to different dialogs and detail sub-apps from other apps. However customers still able to do this, just not so easy at the moment. Hope this helps! |
| Comment by Christopher Zimmermann [ 22/Jun/21 ] |
|
Thanks for your input viet.nguyen, it is appreciated. |