[MGNLUI-3490] Investigate the possibility to streamline form field attributes handling Created: 10/Jul/15  Updated: 15/Apr/16  Resolved: 20/Jul/15

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

Type: Task Priority: Major
Reporter: Aleksandr Pchelintcev Assignee: Aleksandr Pchelintcev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 2.5d
Original Estimate: 1d 7h

Issue Links:
relation
is related to MGNLUI-3451 Checkbox doesn't preserve default val... Closed
is related to MGNLUI-3489 Support field default value for local... Closed
is related to MGNLUI-3424 Allow multi-fields (composite, switch... Closed
is related to MGNLUI-3491 Switching the language in a content a... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: Form field attributes handling
Sprint: Sprint 1 (Basel)
Story Points: 5

 Description   

At the moment we have at least attributes that affect field UI representation and data mgmt:

  • read-only state
  • default value
  • locale

Those three are logically connected and depend on each other, i.e. changing a locale to a new language must ensure the default value is set and should not trigger ReadOnlyException if read-only mode is on.

Currently the support of these attributes is scattered between various components involved in Admincentral form framework, e.g. FieldFactory, Transformer, TransformedProperty and even I18nAuhoringSupport, more to come.

Obviously since amount and complexity of the fields we ship is quite large - there are cases when something works not correctly (e.g. MGNLUI-3488, MGNLUI-3489, MGNLUI-3424, to some extent - MGNLUI-3221).

What we could do - is to take step back and see how we could implement the same functionality given all the features we had to add since the first effort.

The goal would be to try to move functionality to the places where it belongs and to make the handling of these attributes more transparent.



 Comments   
Comment by Aleksandr Pchelintcev [ 20/Jul/15 ]

After a couple of days of investigation I became quite confident that this issue and the consequent ones can be fixed with some refactoring of how we treat and handle the forms (described in the linked page). The approach was tried on the simple fields and the result was quite good - less code and method calls was needed to support i18n, default values and read-only states were handled properly. The case of complex fields (with delegating transformers) was not that well tested, but logically - it should work as well.

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