Merge commit 'schmonz/master'

[git.ikiwiki.info.git] / doc / todo / supporting_comments_via_disussion_pages.mdwn

diff --git a/doc/todo/supporting_comments_via_disussion_pages.mdwn b/doc/todo/supporting_comments_via_disussion_pages.mdwn
index 14a8b3f71a7552b98b4424463af89e5254f7cc98..aae0b3008060994160b2b7207eedd46130fdd3a2 100644 (file)
--- a/doc/todo/supporting_comments_via_disussion_pages.mdwn
+++ b/doc/todo/supporting_comments_via_disussion_pages.mdwn
@@ -45,6 +45,8 @@ Is this simple enough to be sensible?
 
 >>> As a side note, the feature described above (having a form not to add a page but to expand it in a formated way) would be useful for other things when the content is short (timetracking, sub-todo list items, etc..) --[[hb]]
 
 
 >>> As a side note, the feature described above (having a form not to add a page but to expand it in a formated way) would be useful for other things when the content is short (timetracking, sub-todo list items, etc..) --[[hb]]
 

+# [[MarceloMagallon]]'s implementation
+

 I've been looking into this.  I'd like to implement a "blogcomments"
 plugin.  Looking at the code, I think the way to go is to have a
 formbuilder_setup hook that uses a different template instead of the
 I've been looking into this.  I'd like to implement a "blogcomments"
 plugin.  Looking at the code, I think the way to go is to have a
 formbuilder_setup hook that uses a different template instead of the


@@ -80,7 +82,7 @@ Each comment is processed to something like this:
 
 -- [[MarceloMagallon]]
 
 
 -- [[MarceloMagallon]]
 

-# Code
+## Code

 
     #!/usr/bin/perl
     package IkiWiki::Plugin::comments;
 
     #!/usr/bin/perl
     package IkiWiki::Plugin::comments;


@@ -89,14 +91,14 @@ Each comment is processed to something like this:
     use strict;
     use IkiWiki '1.02';
 
     use strict;
     use IkiWiki '1.02';
 

-    sub import { #{{{
+    sub import {

         hook(type => "formbuilder_setup", id => "comments",
             call => \&formbuilder_setup);
         hook(type => "preprocess", id => "blogcomment",
             call => \&preprocess);  
         hook(type => "formbuilder_setup", id => "comments",
             call => \&formbuilder_setup);
         hook(type => "preprocess", id => "blogcomment",
             call => \&preprocess);  

-    } # }}}
+    }

 
 

-    sub formbuilder_setup (@) { #{{{
+    sub formbuilder_setup (@) {

         my %params=@_;
         my $cgi = $params{cgi};
         my $form = $params{form};   
         my %params=@_;
         my $cgi = $params{cgi};
         my $form = $params{form};   


@@ -136,9 +138,9 @@ Each comment is processed to something like this:
         $content.=qq{[[!blogcomment from="""$name""" timestamp="""$timestamp""" subject="""$subject""" text="""$comment"""]]\n\n};
         $content=~s/\n/\r\n/g;
         $form->field(name => "editcontent", value => $content, force => 1);
         $content.=qq{[[!blogcomment from="""$name""" timestamp="""$timestamp""" subject="""$subject""" text="""$comment"""]]\n\n};
         $content=~s/\n/\r\n/g;
         $form->field(name => "editcontent", value => $content, force => 1);

-    } # }}}
+    }

 
 

-    sub preprocess (@) { #{{{
+    sub preprocess (@) {

         my %params=@_;
 
         my ($text, $date, $from, $subject, $r);
         my %params=@_;
 
         my ($text, $date, $from, $subject, $r);


@@ -157,6 +159,62 @@ Each comment is processed to something like this:
         $r .= "</dl>\n" . $text . "</div>\n";
 
         return $r;
         $r .= "</dl>\n" . $text . "</div>\n";
 
         return $r;

-    } # }}}
+    }

     
     

-    1;
\ No newline at end of file
+    1;
+
+# [[smcv]]'s implementation
+
+I've started a smcvpostcomment plugin (to be renamed to postcomment if people like it, but I'm namespacing it while it's still experimental) which I think more closely resembles what Joey was after. The code is cargo-culted from a mixture of editpage and inline's "make a blog post" support - it has to use a lot of semi-internal IkiWiki:: functions (both of those plugins do too). It doesn't fully work yet, but I'll try to get it into a state where it basically works and can be published in the next week or two.
+
+My approach is:
+
+* Comments are intended to be immutable after posting (so, only editable by direct committers), so they go on internal pages (*._comment); these internal pages are checked in to the RCS (although later I might make this optional)
+
+* ?do=smcvpostcomment (in the CGI script) gives a form that lets logged-in users (later, optionally also anonymous users) create a new comment
+
+* \[[!smcvpostcomment]] just inserts a "Post comment" button into the current page, which goes to ?do=smcvpostcomment - it's intended to be used in conjunction with an \[[!inline]] that will display the comments
+
+* The title (subject line), author and authorurl are set with \[[!meta]] directives, just like the way aggregate does it (which means I'll probably have to disallow the use of those \[[!meta]] directives in the body of the comment, to avoid spoofing - obviously, spoofing can be detected by looking at RecentChanges or gitweb, but the expectation for blog-style comments is that the metadata seen in the comment can be trusted)
+
+* The initial plan is to have comments hard-coded to be in Markdown, with further directives not allowed - I'll relax this when I've worked out what ought to be allowed!
+
+I've also updated Marcelo's code (above) to current ikiwiki, and moved it to a "marceloblogcomment" namespace - it's in the "marcelocomments" branch of my repository (see <http://git.debian.org/?p=users/smcv/ikiwiki.git;a=log;h=refs/heads/marcelocomments>). I had to reconstitute the .tmpl file, which Marcelo didn't post here.
+
+--[[smcv]]
+
+OK, the postcomment branch in my repository contains an implementation. What
+do you think so far? Known issues include:
+
+* The combination of RSS/Atom links and the "post new comment..." button is
+  ugly - I need a way to integrate the "new comment" button into the feed links
+  somehow, like the way inline embeds its own "new blog post..." feature
+  (I don't think the current way really scales, though)
+
+* There are some tweakables (whether to commit comments into the VCS, whether
+  wikilinks are allowed, whether directives are allowed) that are theoretically
+  configurable, but are currently hard-coded
+
+* The wikilink/directive disarming doesn't work unless you have
+  prefixdirectives set (which I just realised)
+
+* \[[!smcvpostcomment]] now displays the comments too, by invoking \[[!inline]]
+  with suitable parameters - but it does so in a very ugly way
+
+* Start-tags in a comment with no corresponding end-tag break page formatting
+  (unless htmltidy is enabled - inline and aggregate have the same problem)
+
+* There is no access control, so anonymous users can always comment, and so
+  can all logged-in users. Perhaps we need to extend canedit() to support
+  different types of edit? Or perhaps I should ignore canedit() and make the
+  access control configurable via a parameter to \[[!smcvpostcomment]]?
+  I'd like to be able to let anonymous (or at least non-admin) users comment
+  on existing pages, but not edit or create pages (but perhaps I'm being too
+  un-wikiish).
+
+--[[smcv]]
+
+I've updated smcvpostcomment and publicised it as [[plugins/contrib/comments]]. --[[smcv]]
+
+> While there is still room for improvement and entirely other approaches,
+> I am calling this done since smcv's comments plugin is ready. --[[Joey]]