version=pmwiki-2.2.0-beta65 ordered=1 urlencoded=1
agent=Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080418 Ubuntu/7.10 (gutsy) Firefox/2.0.0.14
author=Ian MacGregor
charset=ISO-8859-1
csum=restore
ctime=1159825157
host=65.102.117.119
name=PmWiki.Comments-UseCases
passwdattr=$1$cXyGi2Sm$hQ0nxUoQ2CsMbsSMV1MAq/
passwdedit=$1$8ItcIEZ8$89VnOvX2sWGNEVQXFBC34.
rev=23
targets=PmWiki.Blocklist
text=!! Case #1: adding comments to the current page%0a%0aThis will probably be the simplest case -- adding a%0a[@(:commentbox:)@] directive should generate a form that%0avisitors may use to add comments to the current page.%0a%0aSome authors and sites will want to have separate 'edit' and%0a'comment' permissions, so that an author can specify that visitors %0acan add comments to the current page but cannot edit what is %0aalready there.  %0a%0aThe page's author should also be able to specify where comments%0ashould be added; e.g., relative to an anchor, the comment box%0adirective, or the top or bottom of the page.%0a%0a%0a!! Case #2: adding comments to a different page%0a%0aThis is the next simplest case, where the author provides a%0aform for adding comments that are stored on a different page.%0aAn example directive might look like%0a%0a    [@(:commentbox MyPage-Talk:)@]%0a%0awhich directs that comments get added to a separate -Talk page.%0aOr, the author might want to simply do%0a%0a    [@(:include MyPage-Talk:)@]%0a%0aand have the commentbox come from within MyPage-Talk.%0a%0aThis case is quite a bit trickier as far as handling of permissions%0ais concerned.  Unlike case #1 above, if an external page is%0aspecified we probably want to prohibit visitors from adding%0acomments to the current page, even though the current page has%0aa [@(:commentbox:)@] markup on it.%0a%0aWe also have to be very careful that the commenting facility doesn't%0aallow lines to be added to arbitrary pages, circumventing the%0aedit password altogether.  (Consider a malicious person adding%0alines to Site.AuthUser or Site.Blocklist.)  %0a%0aAnother key point is that in some environments we may want%0apeople to be able to add comments to -Talk pages even if they%0adon't have read permission to the -Talk page; e.g., if we don't%0awant people to see others' comments.%0a%0a%0a!! Case 3: adding votes or RSVP's to a page%0a%0aWhile not normally considered "commenting", the internal%0amechanics of voting are actually the same as commenting.%0aIn other words, we want a visitor to be able to add some%0acontent (a vote) to a specific page or location in a page%0awithout having to edit the page itself.  For example, %0awe could have a form like (this is a dummy example):%0a%0a>>indent%3c%3c%0a(:input form:)%0aWill you be coming to the party?\\%0aName: (:input text author {$Author}:)\\%0a(:input radio anchor yes:) Yes%0a(:input radio anchor no:) No%0a(:input radio anchor maybe:) Maybe%0a(:input submit post " Add ":)%0a(:input end:)%0a>>%3c%3c%0a%0aand pressing "Add" should add the author's name to a "yes" list,%0a"no" list, or "maybe" list (defined by [@[[#yes]]@], [@[[#no]]@],%0aand [@[[#maybe]]@] tags within the page).  %0a%0aThis is just like commenting except the visitor has an option to%0aspecify where in the page the comment is to be added, and the%0atext of the comment is simply an author name instead of text%0aentered by the visitor.%0a%0aAs with cases 1 and 2 above, "votes" could be added to the%0acurrent page, a different page, or even a separate page for each%0atype of "vote" (e.g., Event-Yes, Event-No, Event-Maybe).%0a%0a%0a!! Case 4:  Conveniently adding items to a blocklist%0a%0aOne of the things that is currently a pain about [[Blocklist]]s is having%0ato edit the blocklist page to add a new term or IP address.  But, this can%0aalso be another form of "comment", since we're simply adding content to%0aa page:%0a%0a>>indent%3c%3c%0a(:input form:)%0aEnter phrase or IP to block: (:input text text:)%0a(:input submit value='Add':)%0a>>%3c%3c%0a%0aHere, we want the permissions to add a new phrase to closely match the%0aedit permissions of Site.Blocklist -- i.e., if someone has edit%0apermission to the blocklist page, then they can use the form to add%0aa new phrase to the blocklist, otherwise they cannot.%0a%0a%0a!! Case 5a: comment form for all pages in a group, comments to original page%0a%0aThis is similar to case #1 above, except instead of a page containing%0athe [@(:commentbox:)@] directive, the directive is placed in the page footer.%0aAnd here, as in #1, we're looking for comments to go directly to the page%0abeing commented upon.  (Comments going to a separate page will be in #5b below.)%0a%0aThis one is particularly tricky, because of the interactions with group%0apasswords.  We obviously start by creating a GroupFooter page that contains%0athe [@(:commentbox:)@] directive, and that causes every page in the%0agroup to receive a comments form.  No problem there.%0a%0aBut if the group has an edit password on it, that would normally prevent%0apeople from creating pages in the group.  We don't want the situation where%0asomeone browses to a non-existent page and then uses the comment form%0a(from the GroupFooter) to create the new page in the group.%0a%0a%0a!! Case 5b: comment form for all pages in a group, comments to separate -Talk page%0a%0aThis is similar to case #2 above, except the directive is in the GroupFooter%0ainstead of the original page, so that it applies to all pages in the group.%0aAnd unlike case 5a above, here we want the comments to go to separate -Talk%0apages instead of the original page.%0a%0aAs in 5a above, we create a GroupFooter with a directive that looks%0alike [@(:commentbox {$BaseName}-Talk:)@], which generates a form that%0aposts comments to the corresponding -Talk page.%0a%0aOne thing that is quite different from case 5a above: in this case, the comment%0afeature ''does'' need to have the ability to create new (-Talk) pages in%0athe group, even if an edit password is set.  This contrasts with 5a where%0awe typically don't want commenting to be able to create new pages in%0aa group.%0a%0a
time=1211940449