[MGNLUI-4275] Default sub-app's component bindings should be exposed to content app choose dialog component provider Created: 22/Aug/17  Updated: 28/Aug/17  Resolved: 24/Aug/17

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: 5.5.5
Fix Version/s: 5.5.6, 5.6

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

Issue Links:
causality
caused by MGNLUI-4180 Conduct UI-related IoC binding withou... 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: Basel 110, Basel 111
Story Points: 3

 Description   

When the default choose dialog definition is provided by the ContentApp class, a large portion of the default sub-app's configuration (browser typically) is applied to it. However, we do not make the choose dialog component provider aware of that sub-apps bindings: the "parent" component provider passed to choose dialog presenter is the one of the app, and only its UI context is considered.

Luckily enough, that does not cause troubles in the default case (like EE webapp without extra mods), since the current IoC mechanism arranges the bindings so that they are easily accessible without extra context required as long as there's no ambiguity (e.g. several context-specific implementations of the same interface).

So it happens that e.g. the commerce tools integration brings in the alternative implementation of e.g. TreeView which already prevents any choose dialog from starting!

In order to fix the problem we need to expose the default sub-app bindings to the choose dialog component provider. Thanks to the new light-weight component providers, that should be not hard at all.


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