[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:
Cloners
Relates
relates to MGNLCT-111 Work with hierarchical external conte... Open
causality
dependency
is depended upon by DOCU-2107 Help customers in configure content a... Open
duplicate
is duplicated by MGNLCT-170 Support multiple node types Closed
relation
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!

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?

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.
2. We are providing auto generated app for defined content type which is clear also.
3. We should also provide the possibility to:

  • Configure an app using multiple node types (node types is somehow physical storage of content types).
  • In such apps, we can provide different actions to different node types, such as open detail action which call corresponding "auto generated app" for each node type.
  • This way, user can easily configure his multi-type app and reference to other sub-apps (detail sub-apps) easily. But user need to configure it based on your needs.
    4. We will not manage "hierarchy of types", the content hierarchy is defined by user when you add another sub-nodes to the parent node. This open up the possibility to freely design the content type hierarchy based on your needs. We can provide restrictions like "availability" so that customer's developer can restrict and manage his system in a structural way, prevent messy content type hierarchy from their side.

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.

Generated at Mon Feb 12 00:37:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.