Uploaded image for project: 'Magnolia UI'
  1. Magnolia UI
  2. MGNLUI-510

Workbench resync is messy

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Neutral
    • 5.0
    • None
    • content app
    • None

    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.

      Checklists

        Acceptance criteria

        Attachments

          Activity

            People

              mgeljic Mikaël Geljić
              mgeljic Mikaël Geljić
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Checklists

                  Bug DoR
                  Task DoD