Revisioned section content support?
tenken opened this issue · comments
Hi --
I stumbled across the Medium site and liked their commenting system. Then I stumbled on your project.
How, or does, your project support comments on content as it goes through revisions? If I have 3 paragraphs and publish my article, and each paragraph gets a comment -- what happens when a new paragraph is added between existing paragraphs, or added to the end of the document?
I see no explanation on how a website should generate a meaningful section-id which could successfully track comments through an articles editorial history.
Bah, hehe. So I'll answer my own question in part -- see:
http://stackoverflow.com/questions/19477494/per-paragraph-commenting-system
The annotations code is custom php code and is independent of the CMS for publishing articles (wordpress VIP). We do indeed store a reference to each paragraph as a row in the database, in order to track any updates to the article content. We call this an annotation thread and when a user saves an annotation the threadId gets stored along with the annotation.
We do not have a unique id stored on the wordpress side for each paragraph, instead we store the paragraphs relative position in that article (nodeIndex “3" and nodeSelector “p” == the third p-tag in the content body for a given article) and the javascript determines where exactly to place the annotation block. We went this route to avoid heavier customizations on the wordpress side, though depending on your CMS it may be easier to address this directly in the CMS code and add unique ids in the html before sending to the client.
Every time an update to an article is published, each paragraph in the updated article is compared against what was previously stored with the annotation threads for that article. If the position and paragraph text do not match up, it attempts to find the paragraph that is the closest match and update the row for that thread and new threads are created and deleted where appropriate. All of this is handled server side whenever changes are published to an article.
Or see, http://tsi.github.io/inlineDisqussions/
Which provides a programmatic ID to be supplied server-side to sections of content (but doens't allude to how):
You can add a data-disqus-identifier attribute to the paragraph to force it to get a specific comments thread
I tried to make this component something that doesn't have much opinion about how you handle your backend for storing comments. Other than the fact that each section which can be "commentable" needs a unique ID, how you do it with your technology stack is up to you. Is there anything I can do to help you out here?
Sorry, this verbiage was a little unclear in that I assumed it was somewhat backend related:
This component manages the interface of how your comments are presented and allows you to decide how to manage your comments on the server.
How about some wording like:
This component provides a display for inline comments on your webpages. Other than requiring a unique ID per section of content, this code provides no mechanism or constraint on how comments are stored server side for your specific application.
If others like myself want to make use of this very cool approach to commenting, trying to centralize some knowledge on how one could create a backend storage scheme for comments would be helpful for wider adoption. Perhaps link the above 2 links somewhere into a "Integration" page.
Thanks for the cool component!
An "Integration" section is a great idea! I'll look into rolling that into the README + Demo site sometime soon. I'll also make the vebrage related to the backend a little more clear. I definitely want to be very clear that this is only an interface component.
Thanks for your thoughts!