Django Forum Demo and Screenshots

Tom September 9, 2007 at 5:28 p.m.

I noticed you went with a very denormalized model structure as well as choosing to do queries "by hand". Were these choices based on anything other than database performance? I only ask because I am in the process of writing my own custom Django-powered forums (without knowledge of this project, unfortunately!) and am taking a slightly different approach, instead choosing to use joins of related models and signals over a highly denormalized/overridden structure.

Also, do you have any plans to implement "bolding" of topics with new posts in the forum details? If so, could you share how you plan to do this? I haven't quite figured out the best method for this yet, at least as it pertains to tracking posts unread/read during a visit instead of just the simplistic "since last visit" topic list. I'm currently set on a simple session system that will track posts viewed and compare it to since-last-visit data (cached).

Finally, what about complex access permissions on a per-forum, per-usergroup basis? I am planning to use an Access Mask system based in part on .htaccess conventions. I am working towards the simplest solution possible that allows for maximum granularity in the perms system.

Good luck on the project and thanks!

Jonny September 10, 2007 at 11:03 a.m.

The denormalised data and the queries which are done "by hand" had an influence on each other.

I was originally just going to have a last post ForeignKey on the Topic and Forum models to simplify display of the last post details for each. Looking at the query logs, I could see that setting the last post from Post's save() method for these objects and calling their save() method was generating an update query containing assignments for every column in the relevant row in the Topic and Forum tables (since Django's ORM doesn't currently only update the deltas), so I wrote methods to execute an UPDATE for the single column I was interested in changing.

Since I was already doing these extra queries and already had a mechanism in place for only updating the relevant columns, I thought I might as well simplify the queries required to display forum and topic listings even further by adding enough denormalised data to reduce the query required for each to a single SELECT.

For tracking of which topics have been read, I might initially just implement it as something as simple as having a model with user, topic and last time topic was viewed, which would be created/updated as necessary when you view a topic. I haven't thought about this one much yet, but it should only require the addition of a LEFT OUTER JOIN onto the new table when displaying topic listings.

Complex access permissions are something else I haven't considered yet. Until I have all the basic features in place I'm taking a simple approach, so my permissions are currently limited to a simple grop flag on user's forum profile which identify them as a user, moderator or admin.

jinzo November 1, 2007 at 7:16 p.m.

Hello, I'm very interested in you forum application, I noticed there was no devolping happening lately, so what's the status ?

I'm interested in helping, mainly adding the features I would need ( bbcode/markdown parsing, better intergration support, bugfixing ofcourse, ... )

Hope you'll have some time to dev again.

Good luck & take care.

Bogdan November 13, 2007 at 10:33 p.m.

Hi.

There seems that something is broken in the demo. It tries to load something from "localhost" (haven't got the time to find out what) -- probably static media files, as I can't see any CSS / pictures.

Jonny November 15, 2007 at 2:48 a.m.

Whoops, development settings ended up in the demo instance after the MEDIA_URL was updated - should be sorted now :)