• View
• Edit
• History
• Print
• Backlinks

Comments-Use Cases

 

Case #1: adding comments to the current page

This will probably be the simplest case — adding a (:commentbox:) directive should generate a form that visitors may use to add comments to the current page.

Some authors and sites will want to have separate ‘edit’ and ‘comment’ permissions, so that an author can specify that visitors can add comments to the current page but cannot edit what is already there.

The page’s author should also be able to specify where comments should be added; e.g., relative to an anchor, the comment box directive, or the top or bottom of the page.

Case #2: adding comments to a different page

This is the next simplest case, where the author provides a form for adding comments that are stored on a different page. An example directive might look like

   (:commentbox MyPage-Talk:)

which directs that comments get added to a separate -Talk page. Or, the author might want to simply do

   (:include MyPage-Talk:)

and have the commentbox come from within MyPage-Talk.

This case is quite a bit trickier as far as handling of permissions is concerned. Unlike case #1 above, if an external page is specified we probably want to prohibit visitors from adding comments to the current page, even though the current page has a (:commentbox:) markup on it.

We also have to be very careful that the commenting facility doesn’t allow lines to be added to arbitrary pages, circumventing the edit password altogether. (Consider a malicious person adding lines to Site.AuthUser or Site.Blocklist.)

Another key point is that in some environments we may want people to be able to add comments to -Talk pages even if they don’t have read permission to the -Talk page; e.g., if we don’t want people to see others’ comments.

Case 3: adding votes or RSVP’s to a page

While not normally considered “commenting”, the internal mechanics of voting are actually the same as commenting. In other words, we want a visitor to be able to add some content (a vote) to a specific page or location in a page without having to edit the page itself. For example, we could have a form like (this is a dummy example):

and pressing “Add” should add the author’s name to a “yes” list, “no” list, or “maybe” list (defined by [[#yes]], [[#no]], and [[#maybe]] tags within the page).

This is just like commenting except the visitor has an option to specify where in the page the comment is to be added, and the text of the comment is simply an author name instead of text entered by the visitor.

As with cases 1 and 2 above, “votes” could be added to the current page, a different page, or even a separate page for each type of “vote” (e.g., Event-Yes, Event-No, Event-Maybe).

Case 4: Conveniently adding items to a blocklist

One of the things that is currently a pain about Blocklists is having to edit the blocklist page to add a new term or IP address. But, this can also be another form of “comment”, since we’re simply adding content to a page:

Here, we want the permissions to add a new phrase to closely match the edit permissions of Site.Blocklist — i.e., if someone has edit permission to the blocklist page, then they can use the form to add a new phrase to the blocklist, otherwise they cannot.

Case 5a: comment form for all pages in a group, comments to original page

This is similar to case #1 above, except instead of a page containing the (:commentbox:) directive, the directive is placed in the page footer. And here, as in #1, we’re looking for comments to go directly to the page being commented upon. (Comments going to a separate page will be in #5b below.)

This one is particularly tricky, because of the interactions with group passwords. We obviously start by creating a GroupFooter page that contains the (:commentbox:) directive, and that causes every page in the group to receive a comments form. No problem there.

But if the group has an edit password on it, that would normally prevent people from creating pages in the group. We don’t want the situation where someone browses to a non-existent page and then uses the comment form (from the GroupFooter) to create the new page in the group.

Case 5b: comment form for all pages in a group, comments to separate -Talk page

This is similar to case #2 above, except the directive is in the GroupFooter instead of the original page, so that it applies to all pages in the group. And unlike case 5a above, here we want the comments to go to separate -Talk pages instead of the original page.

As in 5a above, we create a GroupFooter with a directive that looks like (:commentbox {$BaseName}-Talk:), which generates a form that posts comments to the corresponding -Talk page.

One thing that is quite different from case 5a above: in this case, the comment feature does need to have the ability to create new (-Talk) pages in the group, even if an edit password is set. This contrasts with 5a where we typically don’t want commenting to be able to create new pages in a group.