1

I am working on a user driven cms site. Think of it like stack overflow. The users can write posts, and publish them to the web. I am using a WSGI editor to generate the content.

One of the features I am implementing is the ability for users to comment on particular section of a user post. I am trying to think of a clean way to implement this feature.

My current plan is to customize the WYSIWYG editor to generate a unique id per <p> and then store the comments separately, and when the page loads also read the comments and do some jquery magic. All users that are going to be generating content will be admin users, so I am not afraid of someone messing around with ids.

This is one approach I have found, but I was hoping to either get some feedback or alternative ways to accomplish what I need. Another thing I am trying to figure out is how I can handle a user editing a post that has been commented on...

Nix
  • 504
  • 4
  • 11
  • 3
    Don't trust the client to generate unique ids. Could two clients generate the same id? Could someone insert their own id in the text? If you ever wrote another front end to the site (ios, android), would it need to implement that logic too? Or a web API to add comments? –  Feb 25 '13 at 15:58

3 Answers3

1

Don't let the browser do anything that has some relevance to the database (like generating IDs). Very bad idea. People will use this to send trash data just to see what happens.

Let it send the text, then split into elements, preferably by line endings, you may or may not get those <p> tags. Then let the controller generate ID's for them.

But all in all this sounds complicated and I would just do what most other forums do in similar situations quotes within the answering text:

This is one approach I have found, but I was hoping to either get some feedback or alternative ways to accomplish <Nix>

Maybe add the name of the quoted user. Maybe a "parent" link that shows the original text (similar to Reddit).

thorsten müller
  • 12,058
  • 4
  • 49
  • 54
  • 1
    Users are not generating ids, the wysiwyg is generating element ids, and I am not sure you grasp what I am implementing. The user is reading a post, and sees a paragraph they like to comment on, they click it and add a comment. – Nix Feb 25 '13 at 15:57
  • 3
    The WYSIWYG editor doesn't run in the browser? – thorsten müller Feb 25 '13 at 16:14
  • If someone really wanted to mess with the generated element ids let them, the only people that have access to create content will be admin users. And the person creating content, will not be the one inserting comments. They are two separate people. – Nix Feb 25 '13 at 19:44
  • 1
    That's not exactly a good reason to write insecure code. Anyway it breaks MVC rules, which would be bad design. Customizing the editor in Javascript would (my humble opinion) be more work than doing it in the backend, since the common tools/languages used there should make breaking the input into elements more easy and you don't need to worry about the editors internals. – thorsten müller Feb 25 '13 at 20:40
  • Can you please explain how it breaks MVC rules? – Nix Feb 27 '13 at 14:37
  • Because IDs are database stuff and should be created by the model. So ideal case would be to simply hand the user input (full text from the editor) to the model that than splits it in paragraphs (at line breaks or p tags what works best for you) and write them as single records (ID = autoincrement index). (Assuming something like a 'post' has many 'paragraphs' db structure). Those ID's you can then use when you display them again to hook your comments. (If users can later edit their posts this could still become difficult when paragraphs with comments are removed, but can be handled) – thorsten müller Feb 27 '13 at 14:44
1

I think your concept of having unique IDs per paragraph, with the comments stored separately, is pretty solid. But, like you mention, you are stuck with the problems of users editing their posts.

If you have the revision history of the posts maybe the comments could stay with a particular revision.

You could use a diff tool or a Levenshtein distance calculation to help you decide what happens with a comment. You still have to deal with the questions: Should the comment still stay if a paragraph has been edited? Should the comment be deleted if the paragraph is deleted? etc. But having the work done by a diff tool for example may simplify things for you as it should be able to simply tell you if a line is added, deleted, or modified.

Keeping it simple, if you don't know what has happened to an edited text either delete the comments or convert them from a comment on a specific paragraph to a comment on the whole post (if this is possible).

Chris Kent
  • 219
  • 2
  • 6
0

This algorithm that I recommend depends on maintaining the data model for the operations in your database and using that model to generate the interfaces and the links in the reading mode of the document, rather than allowing direct editing of the main document. A link-based approach in the rendered (not editing) view allows someone to participate in the comment workflow without actually letting them edit the main document directly; you can just use textareas or input fields in the popover or new page-based form for these interactions. I've used this approach for department-wide reviews.

Clicking on a paragraph may not be an obvious behavior for new users. When you generate the id for a comment-worthy component (be it paragraph, list item, blockquote, or such), consider adding a superscripted link at the end with a clear label or icon that invites clicking for interaction. Then either pop over a window with your form, or open a new page (depending on accessibility preferences) to accept that input, keyed to that generated id. You'll have to index that stored comment by the document id and the corresponding component id.

For rendering the comments, when a component has a new comment, you can add a new "see comments"-style link following that original "comment here" link; again, this added link can either pop up a window with the dialog (since it could be one or more contributors) keyed to that component, or link to endnote-style comments displayed conventionally beneath the document. Extra credit for adding disposition controls within each component's group of comments that track how you have used or dismissed the suggestions!

How do you keep all this review interfacing separate from the clean document content itself? For HTML source, I'd keep just the id/name attribute on the components themselves and add the review links at display time based on walking the document tree and applying the links into the DOM before the rendition. I typically have an XML-based source so I use an XSLT template to recognize these nodes and add the markup during the conversion into the HTML result tree. Either way, your original source remains free of comment/review markup except when it is in a view that you intend to allow commenting in. You can turn off this added step when the review is over or when commenting is closed.

Don Day
  • 137
  • 6
  • @Don_Day thank you for your response, the only thing I am really interested in is the logic surrounding how to support paragraph level commenting. Our UI design is already flushed out... – Nix Feb 25 '13 at 19:42