substance-text icon indicating copy to clipboard operation
substance-text copied to clipboard

Comments

Open michael opened this issue 13 years ago • 2 comments
trafficstars

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.

michael avatar Jul 18 '12 21:07 michael

For some reason I think we should not include comments into text directly. They should be handled from outside.

Totally agree here. As for

we should factor out the bookkeeping of annotations in general (even em links etc)...

Isn't this how it's supposed to be from the beginning (separating data from its metadata)? It made sense at first to work with a list within surface while working trough text and surface itself...that said, I can look into passing an external data structure soon, it won't hurt :)

vectorsize avatar Jul 18 '12 22:07 vectorsize

I'll know more once I integrate it with the Composer. We don't need to do guessing atm. Maybe skipping comment support for now makes sense.. and instead make the gang of three work reliably.. (em, strong, link). The rest should be cheap :)

michael avatar Jul 19 '12 02:07 michael