[MGNLUI-2135] Forms and dialogs are not properly decorated Created: 24/Sep/13  Updated: 02/Oct/13  Resolved: 01/Oct/13

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

Type: Bug Priority: Critical
Reporter: Federico Grilli Assignee: Federico Grilli
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by MGNLUI-2195 i18n - Forms and dialogs are not prop... Closed
relation
is related to MAGNOLIA-5332 AbstractI18nKeyGenerator could expose... 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:
Sprint: 5.1 - Final

 Description   

When trying to put the new i18n system in place for the workflow module I realised that many keys I expected the system to generate weren't actually generated, for example the keys for save and cancel buttons are never created or the field labels in forms and dialogs. After some investigation, it turned out that forms and dialogs haven't been properly decorated, i.e. the calls to I18nizer.decorate() are either missing or put in the wrong place. After putting them in the right spots so that the whole object hierarchy is properly decorated, the AbstractFormKeyGenerator has started failing with some NPE which need to be fixed. Furthermore, we miss a KeyGenerator for FieldValidatorDefinition(s). The reason why everything apparently works now, i.e. most stuff is basically translated is because translations are currently hardcoded in configuration but once we clean config up and remove labels, descriptions and other i18n properties then the problem would become apparent.



 Comments   
Comment by Magnolia International [ 30/Sep/13 ]

Fix in commit eee9013e1e03efedf0badf71bcdebcb5f7d8a85c is not passable.

At the very least, hacks checking net.sf.cglib.proxy.Enhancer#isEnhanced should clearly be marked as such.

Client code should not be cluttered with knowledge about how I18nizer does its job.

Either we fix the code flow so that the object is only decorated once, or we decide that it's acceptable to try and decorate them several times and we remove the check from info.magnolia.i18nsystem.proxytoys.ProxytoysI18nizer#decorate. If we decide that such a check is the way to go, then the check should be "hidden" in a I18nizer method.

Removing the hack does not break any single test, can we thus assume it's not needed ?
An actual run shows it seems "needed" (the definition is already decorated when reaching this bit while opening a choose dialog), but the comment pointing to where this would happen doesn't seem accurate.

edit: after further reading, I now see the dialog is already decorated because it is retrieved from an app descriptor which is already decorated indeed.

Generated at Mon Feb 12 08:53:32 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.