[MGNLUI-5652] Non-localised form properties are synchronised even when they shouldn't be Created: 06/Feb/20  Updated: 25/Feb/20  Resolved: 23/Feb/20

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

Type: Bug Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 5h
Time Spent: 3h 5m
Original Estimate: Not Specified

Issue Links:
Relates
relates to MGNLUI-5601 FormView.getPropertyValue fails on NP... Closed
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
Sprint: UI Framework 16, UI Framework 17
Story Points: 8

 Description   

While debugging the validation issues and comparing the state to the old implementation I realised our multi-lang support has a flaw: it'll try to synchronise the non-i18n properties among all the localised representations even though those may be bound to different nodes (e.g. address_en and address_de). In case e.g. a composite field is configured as i18n-sensitive, we expect that its field set is completely disjoint for all the locales.

The statement above also reasonates with in-essential multi-lang form read/write API, which mandates the ability to bind the same form to different items.

As a soluition it is proposed to always bind the form to only single root and consider the i18n setting of the complex child property:

if i18n == true we consider that the whole complex property is i18n-ized and -> has to have completely disjoint representations for every locale. In such case we generate several such representaions bound to single-lang locale context and bind those representations to locale-specific items obtained via item provider strategy aware of locale.
if i18n == false we consider that the property is not locale-sensitive and -> may not have several items to back up the representations, so we only generate one and propagate the parent locale context into it.


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