-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Markers are all you need #4152
Comments
I have nothing to add, +1. |
We need to allow anonymous (or uid) markers. |
And simplify API for creating ( |
All markers should be handled by the
Note that dependent markers should be added using operation, while independent should be only added to the markers collection. Markers collection There should be also
It should be possible to use The API should looks like this:
Docs should be also updated. It should not be needed to understand how live ranges work to learn what markers are, however, there should be |
Of course, I am for this idea, but I don't like the flag name. It's hard to come up with a proper name for this functionality, but the proposed name is not good enough. |
Yeah - I also get the feeling that type names are meaningless - I don't have a better names for those yet. The first thought was:
The other way is to set a flag rather then type as I don't see other types of markers. |
I agree that the name of the flag is not perfect. The problem is that it is not easy to define the second type of markers. They are not using operation, are not send to other clients and not tracked by the history. But on the other hand, they use live ranges so they track changes in the document and react to them, and, since all markers have names, then can be observable, tracked. This is why the best choice seems to be to define them by the mechanism they use. The boolean flag: managedByOperations Methods: writer.setMarker( markerOrName, newRange, { byOperation: true } );
writer.removeMarker( markerOrName ) Note that in creates a nice sentence "set marker by operation". |
Please, let it be It reads better: "set marker using operation" instead of "set marker by operation". You are literally using operation to set that marker so that's better IMO. |
I agree, The boolean flag:
Methods:
|
Other: Provided one API for two types of markers, improved docs. Closes #1086. BREAKING CHANGE: Writer should be now used to set or remove markers, instead of MarkerCollection.
@AnnaTomanek, isn't "managed by using operations" more correct? That's what I understood from https://english.stackexchange.com/questions/217815/what-is-difference-between-using-and-by-using. |
It may be, but I'd propose to keep it simple. Not everyone will (1) know there is any difference and (2) understand what this difference is. IMHO |
@pjasiun, you can sleep tight now ;) |
Sorry, can i check if this has been implemented? Edit: found it - "Name is used to group and identify markers. Names have to be unique, but markers can be grouped by using common prefixes, separated with :, for example: user:john or search:3" |
First, let's put apart (static) ranges, positions, and selection. These are used for different cases, for instance, to create and set the document selection.
I think that the number mechanisms we offer developers to handle the same problem is too big: liveposition, liverange and markers. It looks over-complicated and it is more than most users need. The answer to the question: what is a replacement for bookmarks from CKE4 should be simple. And I think it should be: markers.
This is the complete solution, gives you all what you get using live ranges (or live position if the range is collapsed) but also:
However, there are 2 problems.
First, we create markers much later than we created live ranges. This is why they are described as live ranges with names. To understand makers you need to understand live ranges first, what is wrong in my opinion. They should be described as an easy and ready to use solution, not overlay using another mechanism.
The second problem is that it should be very clear what is the difference between marker added and not added to the document.
They also need to use different API.
We should make it very clear. We could even call these two types of markers differently. What does not help is the fact that the second group is also added to the
MarkersCollection
which is a property of the document, so they are somehow added to the document. Maybe we should reconsider this, for instance,MarkersCollection
could be a property in the editing controller, not the document.The text was updated successfully, but these errors were encountered: