{GSoC 2008}Django-Newcomments : A preview

[Thejaswi Puthraya]

Hello folks,
My exams got done in the first week of May. I was feeling quite bored
and so started working on the project.

I completed a few items from the Todo list but need to complete the
documentation and write more tests.

The code for my project is at
http://code.google.com/p/django-newcomments/
and at
http://gitorious.org/projects/django-newcomments

I also have put up the four demos in the source at:

Demo-1: Using django-newcomments as a standalone app.
http://sandbox.thejaswi.info/example1/authors/

Demo-2: Using django-newcomments placing it in django.contrib.comments
(after removing the current django.contrib.comments)
http://sandbox.thejaswi.info/example2/books/

Demo-3: A simple threaded comments demo (inspired from Eric
Florenzano's project).
http://sandbox.thejaswi.info/example3/comics/

Demo-4: A custom comments demo
http://sandbox.thejaswi.info/example4/messages/

Current Problems faced:
* Abstract models don't allow custom managers. Tickets 7154 and 7252
handle that (I am running trunk patched with ticket 7154).
* Abstract models don't allow the inheritance of the inner admin
class. After a discussion on IRC, I was assured that this was a small
issue that newforms-admin would cover after it supports model-
inheritance. Till then an abstract model designer cannot pass on a
neat admin UI to the user :(

Please do let me know of any suggestions/criticisms and/or feedback.

--
Cheers
Thejaswi Puthraya
http://thejaswi.info/

[Nicolas Lara]

Hello,
I was checking out the project.. So far it looks very good =)

A question though:
I noticed the comments retreived by {% get_comment_list ... %} are
ordered by pk. Is there any plan to include custom ordering? I believe
the default ordering should include replies to old comments after the
objet it refers since I dont see any case in which it would make sense
to have the replies away from the objects being replied upon.

I'll try to play around with your project when I get the time :)

good luck,

--
Nicolas Lara
Linux user #380134
Public key id: 0x152e7713 at http://keyserver.noreply.org/
# Anti-Spam e-mail addresses:
python -c "print '@'.join(['nicolaslara', '.'.join([x for x in
reversed( 'com|gmail'.split('|') )])])"
python -c "print '@'.join(['nicolas', '.'.join([x for x in reversed(
've|usb|labf|ac'.split('|') )])])"

[arthur debert]

Hi Thejaswi.

A couple of suggestions:

Any reasons for having CommentFlag.flag being a string, and not a
foreign key to a FlagType model ? Having them as strings makes it
easier to end up with bad data (misspelling and so forth). Of course
there is always the performance penalty, but it seems worth it.

Also, many times it is useful to keep a "raw" body for a comment (as
the user sent it), but also for performance reasons, a "processed"
version such as html (from markdown or something else). Maybe keeping
both in the db allows for speedier rendering. Then an application can
define somewhere (maybe a settings) which function to process the
comment (markdown, textile, some home made tag removing routine), and
have that run and then persisting both at the database.

Thanks
Arthur

[Will Hardy]

> Any reasons for having CommentFlag.flag being a string, and not a
> foreign key to a FlagType model ? Having them as strings makes it
> easier to end up with bad data (misspelling and so forth). Of course
> there is always the performance penalty, but it seems worth it.

You can do both :-)

Have a FlagType model with a string as a primary key, so you only need
to set flag_id if you already know what string you want. I have to
say, I don't usually mess with custom primary keys in django, and have
no idea if there are downsides in using them. Feel free to correct me
if this isn't a good idea for whatever reason.

Having said that I like the flexible approach of just having a string;
unless you need to store other attributes, there are no great
benefits. Bad data could be seen as more of a usability problem than a
technical one.

Cheers,

--
Will Hardy
w: http://www.willhardy.com.au

[akaihola]

On 22 touko, 18:47, "Nicolas Lara" <nicolasl...@gmail.com> wrote:
> objet it refers since I dont see any case in which it would make sense
> to have the replies away from the objects being replied upon.

I've experimented with both approaches on a couple of websites, and
the "correct" solution depends on
* the number of comments in a single topic
* the frequency of new comments vs. active participants' visit
frequency

On low-traffic sites I've found it much more usable to sort comments
chronologically with no thread indentation. I usually include a
running comment number and the number of the parent comment, which is
also linked to the parent comment's HTML achor. This approach is
similar to Trac's ticket system.

So it would be great to have the flexibility to make both approaches
possible.

[Thejaswi Puthraya]

Sorry for getting back to you so late. Was unwell.

On May 22, 8:47 pm, "Nicolas Lara" <nicolasl...@gmail.com> wrote:
> Hello,
> I was checking out the project.. So far it looks very good =)
>
> A question though:
> I noticed the comments retreived by {% get_comment_list ... %} are
> ordered by pk. Is there any plan to include custom ordering? I believe
> the default ordering should include replies to old comments after the
> objet it refers since I dont see any case in which it would make sense
> to have the replies away from the objects being replied upon.

The ordering is not done by pk. For the default models it is done by
submit_date. For custom models the ordering is whatever you specify
(in the Meta inner class). From your suggestion I've implemented a
setting COMMENTS_ARRANGE_BY_THREAD which arranges the list by thread
rather than by chronological order.

Also included a demo...check out http://sandbox.thejaswi.info/example5/authors/1/

> I'll try to play around with your project when I get the time :)
>
> good luck,

Thanks...wish you the same for your project.

[Thejaswi Puthraya]

On May 23, 5:00 pm, akaihola <akaih...@gmail.com> wrote:

> So it would be great to have the flexibility to make both approaches
> possible.

Now it is possible to do both.

[Thejaswi Puthraya]

On May 23, 7:08 am, arthur debert <deb...@gmail.com> wrote:
> Hi Thejaswi.
>
> A couple of suggestions:
>
> Any reasons for having CommentFlag.flag being a string, and not a
> foreign key to a FlagType model ? Having them as strings makes it
> easier to end up with bad data (misspelling and so forth). Of course
> there is always the performance penalty, but it seems worth it.

Well...this is something that Jacob wrote...so he's the best person to
answer the question.
I could guess and give the answer but I might be wrong.

> Also, many times it is useful to keep a "raw" body for a comment (as
> the user sent it), but also for performance reasons, a "processed"
> version such as html (from markdown or something else). Maybe keeping
> both in the db allows for speedier rendering. Then an application can
> define somewhere (maybe a settings) which function to process the
> comment (markdown, textile, some home made tag removing routine), and
> have that run and then persisting both at the database.

You can always write yourself a filter and render the markup when
required like:

{% get_comment_list for app.model as comment_list %}
{% for comment in comment_list %}
{{ comment.name|escape }}
{{ comment.comment| some_markup }}
{% endfor %}

It doesn't make sense to keep two versions of comments in the
database...but if your's is a specific or a specialized requirement
you are free to write your own custom comments using the same
templatetags (or your own).

[Zhiwu Xie]

Thanks a lot for the good work. A newbie here, and have a question on
the comment model.

Isn't it cleaner to look at the threaded comments in another way, e.g.,
if comment B is a reply to comment A, then the content_object of B is
simply A instead of the original content object a comment is attached
to? That way you can get rid of the 'parent', because 'content_object'
is the 'parent'. You may calculate the 'level' by recursively looking at
the content_object's content_type. If it's not a comment then you've
reached the top of the thread. In this way, a non-threaded comment is
just a threaded comment with maximum level 1, and the post_comment and
reply_comment can be merged.

Also a 'modify_date' may be useful for the abstract comment model. One
of the benefits you might want to provide to the authenticated users is
to modify their comments.

Thanks,

Zhiwu Xie

[Zhiwu Xie]

I wonder if it would be a good idea to put the comment config (e.g.,
threaded or not, maximum length, pre-/post-moderation, etc) into a
separate model, then let all models needing a comment have a foreign key
to the comment config model.

Zhiwu