X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/0b3368cb6b698246cd606e0fbf70a2f9d1aa2b29..651cdd4b2a85f4e5f9d298a7eea7d0e6d94442b1:/doc/todo/supporting_comments_via_disussion_pages.mdwn?ds=sidebyside diff --git a/doc/todo/supporting_comments_via_disussion_pages.mdwn b/doc/todo/supporting_comments_via_disussion_pages.mdwn index 73b71416d..420ae4a7e 100644 --- a/doc/todo/supporting_comments_via_disussion_pages.mdwn +++ b/doc/todo/supporting_comments_via_disussion_pages.mdwn @@ -45,7 +45,7 @@ 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]] -## [[MarceloMagallon]]'s implementation +# [[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 @@ -82,7 +82,7 @@ Each comment is processed to something like this: -- [[MarceloMagallon]] -# Code +## Code #!/usr/bin/perl package IkiWiki::Plugin::comments; @@ -91,14 +91,14 @@ Each comment is processed to something like this: 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); - } # }}} + } - sub formbuilder_setup (@) { #{{{ + sub formbuilder_setup (@) { my %params=@_; my $cgi = $params{cgi}; my $form = $params{form}; @@ -138,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); - } # }}} + } - sub preprocess (@) { #{{{ + sub preprocess (@) { my %params=@_; my ($text, $date, $from, $subject, $r); @@ -159,11 +159,11 @@ Each comment is processed to something like this: $r .= "\n" . $text . "\n"; return $r; - } # }}} + } 1; -## [[smcv]]'s implementation +# [[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. @@ -182,3 +182,41 @@ My approach is: 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 ). 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]] + +[[done]]