[MGNLUI-2822] FieldDefinitionKeyGenerator should be more lenient to the field definitions outside of form context. Created: 24/Apr/14 Updated: 29/Apr/14 Resolved: 24/Apr/14 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 5.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Aleksandr Pchelintcev | Assignee: | Aleksandr Pchelintcev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | i18n | ||
| 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
|
| Date of First Response: | |
| Sprint: | 5.3 Sprint 6 |
| Description |
|
Except for the choose dialog workaround FieldDefinitionKeyGenerator optimistically expects the field definition to be a part of a dialog/editor structure, i.e. relies on the presence of Form/Tab definitions in the parent hierarchy. However, now there are cases when the field is configured not in the scope of any dialog/detail sub-app, but in completely different structures. An attempt to i18n-ize such fields would lead to RuntimeExceptions. The proposed solution is to not make too much assumptions about the FieldDefinition's parents. We would keep the old logic of generating various dialog-ish keys, but also generate a mere all-parents-name based key in case field is defined elsewhere. |
| Comments |
| Comment by Aleksandr Pchelintcev [ 24/Apr/14 ] |
| Comment by Magnolia International [ 24/Apr/14 ] |
|
A few comments:
|