[MGNLUI-510] Workbench resync is messy Created: 07/Jan/13  Updated: 11/Feb/13  Resolved: 07/Jan/13

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

Type: Bug Priority: Neutral
Reporter: Mikaël Geljić Assignee: Mikaël Geljić
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 Description   

on subApp startup or location change, the workbench needs to be restored to reflect the potentially new location. This is currently handled in the following order:

1. AbstractContentSubApp#restoreWorkbench
2. ContentWorkbenchPresenter#resynch
3. ContentWorkbenchView#resync
4. back to ContentWorkbenchPresenter#onSearch - fires a SearchEvent
4b. location has a chance to be updated, which is not needed when restoring the workbench
5. handler in presenter triggers ContentWorkbenchPresenter#doSearch
6. optionally do ContentWorkbenchView.resync

The main problem is that on workbench restore there is a lot of back and forth logic between view and presenter, also even between the presenter and the event bus. Search UI logic was then also spread between view and presenter.

Conceptually, the presenter gets its state and updates the view, the view should not fire things back to presenter in a programmatic way - but only following user interaction, e.g. search field value change, not workbench restore.


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