[MGNLUI-6342] Do not refresh grids in inactive apps and make DatasourceObservation extendable Created: 22/Oct/20  Updated: 14/Aug/23  Resolved: 13/Mar/23

Status: Closed
Project: Magnolia UI
Component/s: None
Affects Version/s: None
Fix Version/s: 6.3.0, 6.2.30

Type: Improvement Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Antonín Juran
Resolution: Fixed Votes: 0
Labels: VN-Testing, ui-devx-impr
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: 1h Time Spent: 1h
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Java Source File MyJcrDataSourceObservation.java    
Issue Links:
Relates
relates to MAGNOLIA-9050 Improve UI push scalability Open
causality
is causing MGNLUI-7913 Initialize AbstractDatasourceObservat... Closed
is causing TASKS-46 Task App needs active refresh to show... Closed
duplicate
is duplicated by MGNLUI-6343 Make datasource refresh local Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLUI-7893 Implementation Sub-task Completed Antonín Juran  
MGNLUI-7894 Code review Sub-task Completed Roman Kovařík  
MGNLUI-7895 Pre-integration QA Sub-task Completed Roman Kovařík  
MGNLUI-7896 QA 6.2 Sub-task Closed Quach Hao Thien  
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Release notes required:
Yes
Date of First Response:
Epic Link: Datasource observation
Sprint: Nucleus 31
Story Points: 3
Team: Nucleus
Work Started:

 Description   

Currently DatasourceObservation#register accepts mere Runnables (i.e. actions without without any inbound arguments), pretty much leaving us with only one observation reaction: "refresh the whole thing". For example, the app will still be refreshed even if the change occurred in an item the user doesn't have access to.

As an optimisation or improvement of the interface, we could consider including addtional information about changed items (and maybe user) when triggering the listeners.

This could potentially save us the effort and CPU resources by letting us skip the actual actions when they are irrelevant, or execute the update in a more intelligent way rather than a full refresh.



 Comments   
Comment by Roman Kovařík [ 24/Jan/23 ]

Potential areas / problems:

  • observation aware of user's permissions
    • we still need to refresh if user has only read access to an item so grids show up-to-date data
    • while it make sense generally to ignore changes in items the user doesn't have access to
      • this doesn't cover corner cases where a custom column value provider might provide data from any part of the JCR tree, in system context (and therefore permissions are not relevant in such case)
  • observation aware of node types
    • generally makes sense to filter only the node types specified by the datasource definition
    • again any custom column might provide data from any other node type / nested node or even outside of the datasource rootPath
  • refresh only relevant items
    • it's possible to use com.vaadin.data.DataProvider#refreshItem avoid refreshing of whole grid
    • in case of adding/removing items, whole app has to be refreshed anyway
  • temporally disable observation for non active apps
    • observation would need to consume location as additional parameter
      • location doesn't have to be yet active when the component (e.g. browser) backend by the datasource is created. In another words, mapping location to observation might not be trivial

 

 

Comment by Thomas Comiotto [ 07/Feb/23 ]

Apart from the inclusion of additional infos in the interface, make the whole thing  pluggable.  It's more or less impossible to replace ootb observation by custom code.

Not really. But still, enhance the interface, please, and let users write custom code that deals with / fits their corner cases.

 

Comment by Thomas Comiotto [ 07/Feb/23 ]

Not sure how to link issues. This is linked to SUPPORT-15832

Comment by Roman Kovařík [ 10/Feb/23 ]

Hey again,

I've checked the plugability question and it seems that although the JcrDatasourceObservation is not directly opened for extensions, it still possible to provide a custom implementation (attached MyJcrDataSourceObservation.javaas an example) as for any other Magnolia component via a module descriptor:

 <components>
    <id>admincentral</id>
    <component>
      <type>info.magnolia.ui.contentapp.observation.JcrDataSourceObservation</type>
      <implementation>info.magnolia.ui.MyJcrDataSourceObservation</implementation>
    </component>
  </components>

 <components>
    <id>datasource-jcr</id>
    <component>
      <type>info.magnolia.ui.observation.DatasourceObservation</type>
      <implementation>info.magnolia.ui.MyJcrDataSourceObservation</implementation>
    </component>
  </components>

The example is just a copy of JcrDatasourceObservation with added check for user permissions and location.

 

Best regards 
Roman

Comment by Thomas Comiotto [ 02/Mar/23 ]

Hello Roman,
Thanks! This kind of works, but the combination of event skipping and permission check  introduces UI inconsistencies (because the permission check takes too long). I did a version that limits the permission check to site folders and stores the result in the session. Will give this a spin on our test server and keep you posted about the results.

Best regards,
Thomas

 

Comment by Roman Kovařík [ 03/Mar/23 ]

Thanks for the feedback!

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