[MGNLUI-5662] Empower developer with ability to apply operations on commited / moved / renamed node in the datasource Created: 11/Feb/20  Updated: 12/Jan/23  Resolved: 12/Jan/23

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

Type: Improvement Priority: Neutral
Reporter: Jaroslav Simak Assignee: Unassigned
Resolution: Won't Do 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)
Date of First Response:

 Description   

Use Case

Apply operations to node that is committed / moved / renamed by JcrDatasource.

Applying the Use Case

This use case comes from the Content Tags module, where we want to scan saved node for mgnl:tags property so can we can create new tags entered by the user.

Having such way of altering the committed node, developers do not need to define custom commit action for each dialog or detail subApp, that allows to enter tags using TokenField.

Content Tags is handling this by extending the JcrDataSource, however it is quite cumbersome:

  • one has to define new impl in the module descriptor and has to be in admincentral scope (if defined datasource-jcr scope, all other impls from ui-framework-jcr are trashed)
  • it is not flexible because only one impl can exist
  • seems too heavy to extend JcrDataSource because of adding tiny piece of functionality

Possible solution could be to introduce commit / move / remove listeners – something like Vaadin's com.vaadin.flow.component.HasValue.ValueChangeListener and collect them using @Multibinding (or some other technique) so they don't need to be explicitly configured on the datasource definition.

 

This functionality cannot be supplied by JCR's observation mechanism, as it would trigger for every node change in every workspace and would be very performance heavy.



 Comments   
Comment by Roman Kovařík [ 12/Feb/20 ]

This functionality cannot be supplied by JCR's observation mechanism, as it would trigger for every node change in every workspace and would be very performance heavy.

I can see info.magnolia.contenttags.TagsModule#tagableWorkspaces. A listener would cover tags added outside of UI as well. Can be started from the module class itself, no need to depend on UI. 

 

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