How to listen for changes

[dlemmermann]

How can an application listen for changes to the text? I am writing the application showing in this screenshot and each item in the list view on the left-hand side represents one document that can be edited inside the rich text editor. Obviously I need to update the document in the list view items whenever the user changed the document. How can I synchronize these two views, what is the recommended way? Currently I have the impression that I have to perform a "save" ... but that can't be right, can it?

[jperedadnr]

So far, there is the modifiedProperty property that tracks if the document has been changed in any way. For now, the demo uses it to change the app title:

Of course, that doesn't give you the changes made, but it is a very cheap way to know that the document changed.

You are right in the save part: for now, the documentProperty is not updated until save is called. And there is a reason for this: saving the document on every little change is a very heavy task that would affect performance (i.e. saving while you are typing).

There are many alternatives that we could explore, like using a background thread that periodically saves the document, or saving when the control is idle and the user stops doing changes for some time.

It might be also convenient to have an extra property (like editedDocumentProperty) that would keep the current document constantly updated.

Thoughts?

[dlemmermann]

I am not familiar with the editing details, but there must be a model somewhere that always is in sync with the latest edits, right? Otherwise, how could you build the list cells and text flows?

[dlemmermann]

I also noticed that saving the document is executed inside a Platform.runLater() which makes my life also hard because I can't retrieve the updated document right after the call to save() and in the meantime the ListView has a new selected element. This new element selection triggered a call to setDocument(). Hard to get this all under control.

[jperedadnr]

As mentioned, the control uses a PieceTable implementation, which uses "pieces" based on user actions. When you open a big document, one single piece is created with the text. However, when the user starts typing, for every single letter, or change in decoration, new pieces are created. This allows for undo/redo management.

"save" is an action that iterates through all the pieces with their big or little text fragments and gets the final text and decorations.

This can be done at anytime, so you can always get the model of what is being rendered at that moment. But we do it only "on demand" for now, when requested by the save action.

As discussed before, we could implement several options like background thread to get a documentBeingEditedProperty that could be listened for changes or autosave on idle

As for the Platform.runLater, I'll see if that can be removed, or we could use another locking mechanism.

[dlemmermann]

For the time being I am listening to the modified property and execute the save action whenever it becomes TRUE. This updates the document property and I can then retrieve the updated document from there. This usually works so fast that I hardly see any delay (if at all). So maybe we could have an option where we tell the rich text area to always update the document property after every change. This should work well for small documents, which is the case for my use case where the user will edit several small notes. If somebody wants to use the text area for big documents then they can disable the feature and they would know that the document property will be updated asynchronously.

[jperedadnr]

Makes sense, we can simply add for now an autoSave property to the control that the user can opt-in/out, based on their needs of small or big documents.

[jperedadnr]

#140 should fix this