[MGNLUI-4566] Polish datasource observation mechanism in content apps Created: 13/Jul/18  Updated: 21/Oct/19  Resolved: 07/Oct/19

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: 6.2

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

Issue Links:
Cloners
clones MGNLUI-4545 Investigate polishing of datasource o... Closed
dependency
is depended upon by MGNLUI-4531 Polish browsing functionality impleme... Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: UI framework implementation
Sprint: Kromeriz 156, UI Framework 7, UI Framework 8
Story Points: 8

 Description   

primary goal

  • get away from the inevitable need of content changed events. In the new incarnation of the content app we try to stay away from the ContentChangedEvent since it is an error-prone and cumbersome way to communicate the changes. Instead we try to utilise the native datasource observation capabilities relief the app developer from having to send notifications manually.
  • browser views should not have any imperative logic re: refreshing the views. Instead e.g. the table should use Vaadin DataProvider API and data providers should optionally subscribe to the backend events

possible solution

  • JCR - use the wrapper around observation mechanism
    • do not want to have too many listeners at once. Maybe create a singleton pool of the listeners, which would broadcast the changes to the data providers?
    • non-JCR: depends on the capabilities of the backend
      • there could be no capabilities (like REST)
      • we could provide e.g. smth like localised CCE: specific action injects the specific DS observation and pushes the event
        additional complications
    • we have some relying on the CCE in other places. E.g. details sub-apps catch them and automatically close once it is received.
    • how do we leverage that situation?


 Comments   
Comment by Roman Kovařík [ 17/Jul/18 ]

Other usages of CCE:

  • info.magnolia.ui.api.event.ContentChangedEvent.Handler#onContentChanged
    • closing subapp when item was deleted
    • changing location when item was e.g. renamed 
    • seems like both cases are not working since MGNLUI-2761 (contentConnector.canHandleItem() added at the begging so a deleted/cahnged item is never handled anyway). Not reported so we probably don't need a replacement for special content change event handling.
  • info.magnolia.ui.contentapp.field.WorkbenchFieldFactory#createFieldComponent
  • info.magnolia.contentapp.app.ui.context.ValueContext seems to be the replacement (used in AddFolder action)
    • select an item e.g. after an edit action
    • info.magnolia.contentapp.app.ui.context.ValueContext seems to be the replacement (used in AddFolder action)
      • only disadvantage is that is has to be called explicitly in every action
      • other solution would be a user scoped observation
    • observation mechanism can't replace this
      • since the change could be done by a completely different user
      • refreshing whole view is easy, send an item specific data change event is cumbersome since the JCR data provides need to work with nodes (convert item <-> UUID) but it doesn't have an opened JCR session
  • info.magnolia.ui.contentapp.browser.BrowserPresenter#bindHandlers
    • CCE is used to select and expand e.g. nodes which were just added
    • similar problem as in the previous case which raises question if the observation shouldn't be really user scoped (this shouldn't be hard to change as JCR event keeps track of the user)
Comment by Aleksandr Pchelintcev [ 18/Jul/18 ]

Thanks for further investigation rkovarik,

  • re: detail sub-app case - indeed it seems like there's a bug in 5.x impl. However, I'd still try to give a shot to a thought about how to maybe gracefully restore that functionality, cause it was kinda useful.
  • WorkbenchFieldFactory doesn't matter too much (it's gonna be re-worked anyway)
  • re: having to update the ValueContext in actions - I thought it would be a reasonable measure, cause it is not so magical (I update the context aka state of UI and I can expect that the UI will react), coding-wise it is not much harder to do than to send a CCE.
  • re: selection/expansion logic - it is kinda covered by subscribing to value ctx changes (already UI scoped)
Comment by Aleksandr Pchelintcev [ 07/Oct/19 ]

The resulting solution involves substantial overhaul of DS observatioin mechanism:

  • DSObbservation interface extracted.
  • Default, manually triggered implementation provided (for the domains that unlike JCR don't have provided automatic observation layer).
  • Observation is automatically wired to content views.
  • Additional tweaks for the background thread notifications also provided.
Generated at Mon Feb 12 09:17:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.