[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 ]

commit:
https://git.magnolia-cms.com/gitweb/?p=magnolia_ui.git;a=commit;h=ec2e2bc4d049710e9411d7de953098db558ae41c

Comment by Magnolia International [ 24/Apr/14 ]

A few comments:

  • Kudos on the added test, but I would suggest to:
    • call the interface method of I18nKeyGenerator rather than keysFor(List...)
    • assert on all generated keys, serves as example/docu as well
  • While you were improving the hack to ChooseDialog, we might as well compare either the FQN or do class.getSImpleName() no?
  • And one last thing - the getParentName() method might be beneficial up in parent classes. Since this is for 5.3, we should be able to do this. Please have a look at AbstractI18nKeyGenerator#getIdOrNameForUnknownRoot because it might be somewhat similar to what we're doing these but only for the root rather than for the "chain" of parents, but both would be useful IMO.
Generated at Mon Feb 12 09:00:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.