New APIs: UnlockRule and LockContext

Development
1

Hi everyone,

When we added support for bypassing the document edit lock if a Netflux / ChainPad realtime session is available (for realtime CKEditor) we did a hack by overwriting the default XWikiDocumentLockEditConfirmationChecker component with another component XWikiRealtimeDocumentLockEditConfirmationChecker that has a higher priority. Even though its name was generic, the implementation of this new component was specific to Netflux / ChainPad.

We are now working on integrating BlockNote (to replace CKEditor) which uses a different realtime engine, based on Yjs. We need to implement the same edit lock bypass for BlockNote realtime as well (Loading...). Refactoring XWikiRealtimeDocumentLockEditConfirmationChecker to serve both ChainPad and Yjs proved to be unfeasible: it’s not easy to have a common interface because the way ChainPad and Yjs realtime sessions are bound to an XWiki document is quite different.

In the end I opted for refactoring XWikiDocumentLockEditConfirmationChecker to support the concept of UnlockRules. The idea is to allow extensions to bypass the edit lock when some conditions are met, by providing an implementation for the UnlockRule role. XWikiDocumentLockEditConfirmationChecker checks if there is any UnlockRule implementation that is satisfied.

UnlockRules are components so they can inject other components needed to perform the evaluation. In theory, the rules can leave without any explicit input. In practice, we have only two rules, for ChainPad and Yjs, and they need more or less the same information, which is not free to compute (e.g. determine the current edit mode or the editor to be used for editing the document content). In other to have this shared information computed only once I introduced a LockContext, that is passed to each UnlockRule when they are evaluated.

Let me know if you think these new APIs are not a good idea:

If you have suggestions for better naming I’m all ears.

Thanks,
Marius

2

I’m fine with the naming and the idea, though I’m surprised to see new APIs being introduced in oldcore.
What happens when zero unlock rules are defined btw?

3

Document (edit) locking is a core feature, provided by oldcore. What would be the alternatives:

  • a new module? It would hold for now only UnlockRule and LockContext. As for naming, only documents can be locked, so it would have to be something like xwiki-platform-document-lock. Or xwiki-platform-lock, if we think the locking mechanism will be made more generic in the future.
  • an existing module outside oldcore, maybe xwiki-platform-model?

I’m not convinced, so I prefer to keep it simple for now.

The document is not unlocked automatically. You get the edit lock confirmation message with the option to force the lock.

Thanks,
Marius