[pmwiki-users] blog comments (was: pagelist formats and orders)

[Bronwyn Boltwood]

On 2/21/06, Hans <design at softflow.co.uk> wrote:

>  Tuesday, February 21, 2006, 7:36:36 PM, Bronwyn wrote:
> > That does bring up a wishlist item, though: better recent
> > comments functionality, for sidebar display and full-text feed.
> > Compare the Recent Comments at
> > http://headrush.typepad.com/creating_passionate_users/ with the one
>  > at http://softflow.co.uk/design/Blog/Blog  .  Hans' comments
> > implementation is ingenious, but it's just not the same.  What kind
> > of guidelines are you using for how comments should work and what we
> > should be able to do with them?
>
>   At headrush.typepad.com comments are part of the blog page, and on my
> own simple blog comments are on separate wiki pages, which has its own
> advantages and disadvantages. Maybe the speed of showing comments is
> more important than managing them on separate pages, in which case we
> can try to build them into the blog pages. This should make it a  lot
> easier to construct. Just add the commentbox to the group footer of
>   BlogPages.

My point was that PmWiki can't yet generate the same format of recent
comments listing as most blog engines do, namely "<Commenter> on <Post
Title>". There's no simple way in PmWiki to do a feed like:

	!!!!!<Commenter> on <Post Title>
	<full text of comment>
	
	!!!!!<Commenter> on <Post Title>
	<full text of comment>

Or a sidebar list like

	* <Commenter> on <Post Title>
	* <Commenter> on <Post Title>

The fundamental problem is that PmWiki doesn't have the concept of
comments as entities in their own right that are associated with a
bigger entity, the post upon which they comment.  To have good
blogging support, it needs to acquire that concept.  Hans, you've done
a damn fine job of working around that flaw, and Pm should adopt your
system unless he's got a better idea in that cortex of his.

So, how should comments work?

They should be stored separately from posts, even though they are
associated with specific posts.  It will be easier to maintain posts,
and to make separate feeds and sidebar widgets for latest posts and
latest comments.
-- Keeping the comments to BlogPosts.SamplePost in
BlogComments.SamplePost or BlogPosts.SamplePost-Comments makes those
feeds and widgets easy.

Comments should not be displayed with their posts in front page or
archive listings.  Instead, there's a link saying "XX Comments", which
goes to the post's page at the anchor for the comments, which are
displayed underneath the post.  The comment form is displayed
underneath the existing comments, and has an anchor.  Posts often have
"Add a comment" links that jump directly to the comment form,
bypassing the 36 existing comments.
-- Hans has pulled off most of this with his ingenious use of group
headers, footers, and includes.  And he's either licked or is about to
lick the "XX Comments" and "Add a comment" links.

Authors can turn off commenting for specific posts.
-- A simple (:nogroupfooter:), and it is done.

Comments are counted.  Archives often show how many comments each post
has.  Sorting the list by number of comments would be nifty -- I
haven't seen that feature very many places.
-- Hans has a counter, but we can't sort by number of comments.  Not
that's a big deal, but it'd be cool.

Comments have ID numbers and anchors, so that it is easy to link to or
quote specific comments.
-- We don't have these.  I don't have the coding chops for it, but
it's probably not *that* hard to do.

Comments have metadata, and skin authors will want style hooks for it.
 The comment ID number is one such piece of metadata.  The date and
timestamp, and the commenter's name are essential.  A lot of blogs
also ask for the commenter's URL and email, and optionally remember it
all in a cookie so that you don't have to retype it every time.
-- The commentbox script does timestamps and asks for names, but not
all of the rest.

Comments need to have some spam protection.  We should be able to turn
on URL approval for comments (separately from the wiki) and/or limits
on number of links per comment.  Setting a time limit for when
comments can be made -- e.g. "up to 6 weeks after the post is created"
-- is another common method.
-- I don't think we have any of this.

Bronwyn