[MGNLUI-6139] Should inform developer when an invalid field is used on a Vaadin declarative layout for a form Created: 17/Jun/19  Updated: 10/Mar/21

Status: Accepted
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christopher Zimmermann Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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
Epic Link: Declarative layout

 Description   

When a developer places a field on a vaadin declarative layout which is used for a form, but the property is not defined on the form:
1. The system should not persist any content entered into this field into JCR (because the form definition should be the only definer of the content model)

This is currently implemented, but should be removed:
"It is possible to bind non-Magnolia fields. You do not need to define a form property in YAML before you can use it in the template. Instead, you can insert the component directly into the template. For example, with <vaadin-text-field caption="email" _id="email"/>, you can create a text field as well as store that value in the JCR path specified by the _id attribute email."

2. The system should inform the developer that the field is invalid.How best to do this needs some discussion on technical feasability.
Ideally via a visible indication in the form rendering. Also as a warning in the log, and maybe as a problem in the definitions app.

See: https://documentation.magnolia-cms.com/display/DOCS61/Form+definition+-+6+UI?focusedCommentId=194486592#Formdefinition-6UI-Declarativelayout


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