Comments #21
Description
Good points you made in the TODO list. There are two use-cases (at least in the case of the composer).
- Adding annotations / comments during editing
- Adding comments (as a reader) later but they're stored on the document.. not on the text node.
While we could definitely store some notes with links etc. I see the commenting use-case as something separate that is controlled from outside. For the composer I'm not sure if adding comments should be part of the text editing workflow, as comments should be something that stick on a document in the first place and refer to a particular part in the doc (e.g. a particular image). For some reason I think we should not include comments into text directly. They should be handled from outside.
I thought about this. Why not defining a comment API for every Substance Node type. The node implementation (e.g. Text, Image) must implement that API. Text is a specific case because the comment might not refer not just to the entire paragraph but to a particular text selection.
However.. comments should be controlled from outside.. they're not even stored on the node... but on the document. So comment deletion does not need to be handled by Text...
Those are the pieces we need.
// say `node` is a regular content node
// init comments
node.feedComments(commentlist); // already registered comments (the document knows about them, feed them in.. nothing is displayed at first)
// once the comments are feeded there's a dependency.. so we need a mechanism to notify the document if changed content effects existing comments so the datastructures can be updated accordingly.
// add a new comment (for text nodes the current selection is considered for determining start and endpos, for image nodes.. we don't need the start end data)
node.addComment({content: "asdfadsf", user: "/user/foo"});
// show all comments
node.showComments();
// unveil a particular comment..
node.showComment(commentId);
// hide comment markers
node.hideComments()mhh.. now that I wrote this.. maybe we should factor out the bookkeeping of annotations in general (even em links etc)... so that they're done in a separate external data-structure that you just pass to the Substance Text constructor.