-
Improvement
-
Resolution: Unresolved
-
Low
-
None
-
None
-
None
-
None
Added business value
Low. It's only about how MultiField nodes look in JCR view - whether they are named consistently. Does not affect functionality.
Current situation
Once MGNLUI-6190 / MGNLUI-6253 is integrated, we'll allow resolving multi-field nodes that do not follow the naming convention strictly. However, such nodes retain their inconsistent names.
E.g.
multi: 0: field: 0_value 00: field: 00_value multi: field: someText_value multi1: field: someText1_value something1: field: someText1_value someText1_de: field: someText1_de_value
would, after resaving, turn into
multi: 0: field: 0_value 1: field: 00_value multi2: field: someText_value multi3: field: someText1_value something4: field: someText1_value someText1_de: #stays ignored b/c of locale suffix that will cause the node not to be resolved field: someText1_de_value
So the prefixes stay empty or whatever they were before, and the numbers get updated.
The implementation reuses whatever prefix it finds via regex when handling a node. This means inconsistent prefixes stay inconsistent.
Desired situation
- Either we will rename the node after resolving right away since we detect its name is bad (this would be a change outside of OrderHandler, and not sure if it's possible)
- or the order handler will have to know the MultiField's name so it can stop guessing the prefix and replace whatever is there.
Or we won't care about it. It's only a question of looks in the JCR browser.
Acceptance criteria
- split from
-
MGNLUI-6253 Allow MultiFields using jcrChildNodeProviders to read children regardless of their names (followup to 6190)
- Closed