[MGNLUI-3469] AbstractCustomMultifield breaks the recursive locale resolution of Vaadin components Created: 22/Jun/15  Updated: 15/Apr/16  Resolved: 22/Jun/15

Status: Closed
Project: Magnolia UI
Component/s: forms
Affects Version/s: 5.4
Fix Version/s: 5.4

Type: Bug Priority: Critical
Reporter: Aleksandr Pchelintcev Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 0
Labels: i18n, multifield
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File config.modules.samples.dialogs.samplesFieldShowRoom.form.tabs.tabMulti.fields.configuredMultiple.xml    
Issue Links:
Relates
relates to MGNLUI-3169 I18n'ize complex fields Closed
dependency
is depended upon by MGNLPN-212 Adapt to Vaadin 7.4 API changes. 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
Date of First Response:

 Description   

Vaadin Component#getLocale() method implementation works be the following principal:

  • Recursively go up the component tree and pick the first non-null locale encountered
  • If the top of the hierarchy is reached (UI component is the last) - grab the locale from VaadinSession ~ HttpSession

AbstractCustomMultiField breaks the recursion because it overrides both setters and getters and maintains a local field for locale, never calling a super-method => session-fallback is never used.



 Comments   
Comment by Aleksandr Pchelintcev [ 22/Jun/15 ]

Removed a locale field in AbstractCustomMultifield, removed overriding getter, so that the vanilla Vaadin recursive approach of resolving the locale is maintained.

Comment by Mikaël Geljić [ 03/Jul/15 ]

This had to be there for a reason. Judging from my comment on MGNLUI-3169, this could be the following:

4. MultiField and CompositeField were not locale-aware, thus new entries were never i18nized, hence the missing (en) suffixes. Now they are.

—it's at least unclear if this is now obsolete after the Vaadin upgrade.

+ Gotta like integrated ticket without a fixVersion

Comment by Mikaël Geljić [ 03/Sep/15 ]

Successfully verified against 5.3.10, 5.4.1 and 5.4.2-SNAPSHOT (just for the sake of completeness because of the major field+i18n improvements from MGNLUI-3489).

  • I could not reproduce the suspected missing (en) suffix on new entries.
  • Use case was multivalue field > composite field > text field; the first two are not localized (same set of entries), only the text one is. See attached field-definition.
  • Indeed, it's only working reliably when using the Delegating(MultiValue|Composite)FieldTransformers, which calls again for making them the default transformers
    • No rush, yet we need a suitable plan to shift towards this.
Generated at Mon Feb 12 09:06:56 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.