They are many commenting systems out there for Plone, Zope 3, etc.
But let’s take this simple statement : why a content provider like any Zope-based application should deal with comments ? A comment is a simple piece of text, that refers to a page and maybe to another comment. There are no workflow needed in most cases. Maybe an authorization required to add the comment but that’s it. And how do you provide a comment on a page that is not generated by your web server, but that is displayed somewhere to your users nevertheless ? (like a static page)
So, looking at how Deliverance works, and because I want to have comments on Sphinx pages, I thaught of a simple way to deal with comments: A WSGI Middleware/Proxy.
The comment application stores comments in a SQL DB and use the pages id (the full URL) as references. I can even use services like Akismet to avoid spams. Then when the page is displayed, I can inject the comments associated to it on-the-fly, and provide a JS-enabled form for people to add comments (which can be caught when submited by the middleware too I guess, or sent through Ajax to a small JSON-enabled service that listens)
This is perfect for an hybrid environment where you have pages generated by various web applications.
Of course there are some caveats, like if the page is gone, or has moved. But dealing with orphan comments should be doable.
We might try that out soon for Afpy.org
Interesting, what is the level of accessibility of your JS-enabled form?
A flat, regular form with a simple button so it stays WAI compliant.
Then a non-obtrusive Javascript that would fold it and make it possible to send the comment through Ajax, and update on-the-fly.
The only problem I can see is that the same url leads to a page that can have different states of comment. But this is OK i guess, since it is only on the commenter page.
I think that commenting may not be quite as “minimalist” as describe.
First, spam protection (e.g. via Akismet) pretty much requires workflow (submitted>akismet likes>akismet unsure>approved).
Second, for many (but not all) sites, comments are important “content” that one would want to be able to index/search with Plone.
Sites that gets lots of comments need to be able to support moderation, simple rating (e.g. “report this comment as abusive to the moderators”), threading, etc.
All these problems are solvable, of course. But it’s a pretty rich problem space, which is why Plone’s current, minimalist system is showing its age and really needs a champion.
http://www.openplans.org/projects/paris-bobun-sprint/commenting ?
I already had that idea – I just never wrote about it
A very feature-rich “comment server” written in Python is an interesting idea. Why have plone.comments, grok.comments, sphinx.comments, django.comments, turbogears.comments, etc. when you could have a single python commenting system?
The integration layers between each system however could mean that instead you might wind-up with more code – you could have python.comments (the server) and then plone.commentserverintegration, grok.commentserverintegration, sphinx.commentserverintegration, django.commentserverintegration, turbogears.commentserverintegration, etc. etc. to deal with indexing comments for local site search, deleting comments when the resource is deleted, resources being moved, integrating user profile information, authentication, comment moderation, etc.
But you might not want or need very tight integration. Integration would also be easier and more performant at the WSGI-level, but it means the comment server is limited to Python apps only – REST-style integration would be worth considering.
An interesting idea nonetheless – however your headline of, “Simplifying the commenting system” brings to mind Faassen’s law, “Nomen simplex est omen contrarium.”
(A simple name is an omen of the contrary)
Please, if implementing a comment system, use the widely-implemented and vendor-neutral OpenID system for people to identify themselves.
@Jon, for the Aksimet protection, if you provide another application that let you unspam or treat the comments marked as spam, “à posteriori”, you can solve that. I agree this make the whole thing more complicated.
For the indexing, unless it is a forum, my minimalistic view is that I don’t see comments as part of the content. If there’s a comment on the content, it is probably because the content has to be changed with what the comment suggests for instance. OTHO, we are starting to think about indexing part of the content outside Plone at Afpy, to provide an hybrid search page that would combine results from Plone and from another indexer.
And in any case, we could use something like Google Custom Search and don’t even worry about indexing (as long as it is a public site of course)
But I agree, it is not obvious to build for all needs.
@davewave : IIRC this is in plone itself, so you can’t comment a page that is statically provided by Sphinx for instance. Think about this use case: on my Plone site I am adding a /docs folder driven by Sphinx with a special Apache rule. How can I provide the commenting feature there ?
@Kevin: if we need to add code on commented applications side, we would lose part of the benefit imho. But maybe an hybrid approach is possible yes. And for the title, yes, it fails in that law for sure
. I should have called it “One commenting system to rule them all” maybe.
@Ben: In a WSGI environment, a commenting application wouldn’t take care of identification imho and would just raise unauthorized errors, so another tool like repoze.who can take care of that. That’s the sweet part of WSGI: each application can focus on one thing, and use web standards to stay compatible with other pieces job.
Tarek, sure, I understand the use case. We’re not talking about the same stuff, for sure
“use the pages id (the full URL) as references” -> the UID, to be robust against moves and name changes.
I agree with Jon that comments should be Plone content and searchable, referenceable, etc.
This use case is a WebOb example:
http://pythonpaste.org/webob/comment-example.html
WTTF is always here to help. ,