[MGNLCT-165] Type without properties results in un-extendable app Created: 21/Oct/20  Updated: 12/Jul/22

Status: Open
Project: Content Types
Component/s: None
Affects Version/s: 1.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Chris Jennings Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File app.yaml     PNG File app_with_no_add_action.png     File type.yaml    
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)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Magnolia supports extending content apps generated from content types. However, if I create a type with no properties, intending to set all properties via a manually configured app, my derived app has a details subapp of type ConfiguredSubAppDescriptor rather than DetailDescriptor.

As the ConfiguredAubAppDescriptor has no method setForm(), my app config cannot add a form and the definitions app shows the warning:

Property [form] not found in class [info.magnolia.ui.api.app.registry.ConfiguredSubAppDescriptor], property is not assigned

And the resulting app offers no "Add item" or "Edit item" methods.



 Comments   
Comment by Christopher Zimmermann [ 22/Oct/20 ]

I understand the use case here, it follows from the fact that the content type can do a lot but it cannot do all the things that you can do in a full form definition in an app.

The "conenttype-centric" appraoch is that one does as much as they can in the content-type, and then simply add or override with whatever that they need via a few fine-tunings in the app file.

But in some cases this would then be MORE complicated then simply defining the full form in the app definition. Or another usecase is that a developer already has a full form (maybe they had a full app that they want to simplify.)

One could argue - why use a CT at all in this case? The answer is that it supplies all of the actions and subapp configuration. 
--------
As a developer I would expect what Chris Jennings posted to work. 
Since it does not work, we should document right away that it is not supported, perhaps with the workaround of supplying one property in the CT file. (I guess that works? Need to check.)
--------
In general we should strive to do things more CT-centric as this is going to become more important (with rest-endpoints and refernce resolving, GraphQL etc), but in the meantime we should accept the current reality and help devs do their jobs as long as it is not going in the wrong direction or is too difficult to support.

Comment by Chris Jennings [ 23/Oct/20 ]

Thank you for your input, 'Topher.
I can confirm that adding just one property to the CT solves the issue.
See: https://git.magnolia-cms.com/users/chris.jennings/repos/multi-field-reference/browse/contentTypes/type.yaml

Comment by Thomas Duffey [ 12/Jul/22 ]

Just ran into this. If you truly don't want another property you can just define the name property that is supposed to come in by default:

datasource:
  workspace: stuff
  namespaces:
    some: https://www.curriculumassociates.com/jcr/1.0/some
autoCreate: true

model:
  nodeType: some:stuff
properties:
  name:
    $type: textField
    required: true

Note you have to re-specify the required attribute for some reason.

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