As a user I can interact within a content app and all components (workbench, actionbar, details) are up to date so that I am not confused
(MGNLUI-1288)
|
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | framework |
| Affects Version/s: | 5.0 |
| Fix Version/s: | 5.0 |
| Type: | Sub-task | Priority: | Critical |
| Reporter: | Mikaël Geljić | Assignee: | Mikaël Geljić |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | workbench | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Date of First Response: | |||||||||
| Sprint: | Beta 2 | ||||||||
| Description |
|
If multiple workbench subapps are open simultaneously, e.g. Security app + Contacts app = 5 Workbenches; then they are all updated when performing a repository operation in one of them. ContentChangeEvents are fired on admincentral event bus, and are then listened to in the ContentWorkbenchPresenter(s). The problem is that this handler also refreshes selection and updates action bar preview, so it will try to do it as well in inactive subapps, whose selection should be left untouched, and which might even operate on a different workspace. |
| Comments |
| Comment by Tobias Mattsson [ 10/Apr/13 ] |
|
ContentChangeEvents should be fired on admincentral event bus, no problem there. The event is intended to allow apps to update their view state when content is changed elsewhere. Apps must not use it as a way to coordinate selection between the different components of an app. |
| Comment by Tobias Mattsson [ 16/May/13 ] |
|
As part of |
| Comment by Mikaël Geljić [ 16/May/13 ] |
|
Commits on that ticket used to prevent refreshing all 3/4 content views in each workbench, but only the active content view instead. This is still valid: WorkbenchPresenter only refreshes its active content presenter. As for the more global issue, this was indeed fixed in Will rename this issue to the more specific content-view pb. |