DocumentUpdatedEvent and XWikiDocument#getLock

Hi,

When a DocumentUpdatedEvent is raised, it’s done before the lock on the page is released. Unfortunately, that means that getLock returns a lock in both the case where the user is actively editing the page and clicks “Save”, and when the user has finished and clicks “Save & View”; I.e. you can’t use the lock to determine a difference between those actions.

Is there another way to determine the difference within an event listener in an extension?

Thanks in advance,
Alex

Hi,

to my knowledge there’s no way in an event listener to know if the save was triggered by a save&view or a save&continue: the page could also have been saved by a REST API calls, or even by a velocity script. So the fact that a user clicked on a button or another is completely independent from this event.

For what reason do you need that information?

Ok, thanks @surli. I had forgotten about saves via REST API or Velocity so you make a good point.

I have an extension that calls out to another service when a document is saved. If I could distinguish between save&view vs save&continue (REST API and Velocity saves would be considered save&view, if I were to guess without thinking it through properly) it would help reduce the time I need to wait in the other service in order to “debounce” the events before acting on them.

In other words, I’d like to be able to more accurately guess when a user has finished editing the page/document whilst keeping things timely. Roughly speaking, a save&view would be an indication they are “done” (with a shorter amount of debounce in case they do happen to start editing again) in comparison to save&continue which could be interpreted as an indication that they are continuing to edit the document and not yet “done”. Obviously what I’ve described is not 100% accurate but without being able to detect the difference between save&view vs save&continue, the debounce has to be longer in order to wait for enough silence in order to assume the user is “done”.