Closed aaalsaleh closed 9 years ago
On the face of it that changes looks like it might be very complicated, do you have an example of why something external would want to manipulate the undo log?
I think it might be better if we allowed you to specify a replacement for the default undo manager rather than trying to implement this ourselves on your behalf.
That is basically the idea, making the undo manager an external plugin. It is not necessary that external components could manipulate the undo stack. As you stated, this can be done by those who needs it once it is an exchangeable plugin. The important thing is at least allowing the possibility for sharing the undo stack between one or more scribe instances.
One example for scribe specifically: two or more instances of scribe on the same page (e.g. summary and full article) that can be edited simultaneously. You can make edits here and there interchangeably. It would be useful for some applications if the undo stack was shared between them as if it was a single document.
Another example for scribe with other components: one or more scribe instances along side other input components in a web application. The user could implement their own global undo plugin that can handle both scribe and other components and use it as scribe's undo manager. This will allow the user to implement a global undo manager and use it with scribe.
Okay, if its urgent I'd suggest submitting a PR otherwise at some point I'll look at making the transaction manager pluggable
Here you go
@aaalsaleh :clap: :clap: :clap: :cake:
@rrees I think we can finally consider this implemented :wink:
It would be great if the undo manager could be shared across multiple instances. One way to do that is to make the undo manager as a plugin that can be instantiated by the user once and used by multiple scribe instances (shared), or an instance for each scribe instance (exclusive). To make this work, each undo transaction should keep a reference to the scribe instance it belongs to (source of transaction).
This can also allow the undo manager to be extended and used by other non-scribe components on the same page. Of course, these components need to define and push their own transactions according to the undo manager API. This leads to a more streamlined undo manager across the whole page or web application.