From 8ff9430a7db0a30fe2f2a0a8c0d91a0f196b1fb4 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Sun, 21 Sep 2008 18:12:08 -0400 Subject: Reference and describe my implementation --- .../supporting_comments_via_disussion_pages.mdwn | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'doc') diff --git a/doc/todo/supporting_comments_via_disussion_pages.mdwn b/doc/todo/supporting_comments_via_disussion_pages.mdwn index 80b375db3..e0495c8c2 100644 --- a/doc/todo/supporting_comments_via_disussion_pages.mdwn +++ b/doc/todo/supporting_comments_via_disussion_pages.mdwn @@ -182,3 +182,34 @@ 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]] -- cgit v1.2.3