Дмитрий

Подумай, как в случае с AJAX сервер будет отдавать сообщения.
В случае с websocket всё просто: список подключённых пользователей известен. Подключился новый пользователь, на сервере вызвался callback, соединение создалось и добавилось в список всех соединений. При получении сообщения от клиента сервер просто пройдёт в цикле по этому списку соединений, отправит данные и забудет про них. Пользователь отключился, вызвался callback, соединение удалилось из списка на сервере.

А как в случае AJAX? Сервер не знает, сколько пользователей активно в данный момент. Клиент отправил запрос, создалось соединение, запрос пришёл на сервер, сервер ответил на него, соединение разорвалось. Если юзер уйдёт с сайта, то сервер просто не будет получать запросы. Как он определит, ушёл ли юзер или просто таймаут ещё не сработал? Можно, конечно, на сервере хранить список с пользователями, которые что-то прислали и раз в N секунд выкидывать протухших. Но это дополнительная нагрузка на серв, который и так будет нагружен огромным количеством периодических запросов (выгоднее держать 1000 открытых соединений, чем раз в секунду открывать и закрывать по тысячи соединений).
Вот тебе ещё простой пример: есть 3 пользователя. Один ничего не пишет и каждые 3 секунды отправляет запрос на получение сообщений. 2 других каждые полсекунды отправляют сообщения. Сервер может только догадываться, в сети ли необщительный юзер, или у него таймаут не вышел. А до тех пор, он хранит все сообщения от 2-го и 3-го пользователей. Но они уже получили сообщения друг от друга, поэтому надо где-то хранить инфу для каждого пользователя, какие сообщения он уже получал, а какие - нет. Можно, конечно, и сообщения хранить только некоторое время, и отправлять на клиент всё, что есть, а уже на клиенте пропускать дубликаты. Но это, опять же, доп. нагрузка на сервер и клиент.

В итоге, надо придумать довольно сложную логику хранения информации, которую надо отправить пользователям, да и список самих пользователей как-то хранить и мониторить. В итоге, куча малких запросов. которые будут просаживать сервер и нетривиальная система оповещений, которая, скорее всего, будет часто выдавать ошибки.

Element.objects.filter(data__showing=2, data__useractive=user.id).aggregate(sum_weight=Sum('weight'))

Первый вызов rand показывает в какие "проценты" попадает следующее число, а потом дергается второй раз rand с нужными границами для получения самого числа, причем границы в зависимости от первого.

Касательно же случайности-неслучайности, rand в вашем случае наверняка не выдает случайной (!!!) последовательности.

В классе админки нужно добавить:

def icon_tag(self, obj):
    if not (obj.pk and obj.icon):
            return ''
    return u'<img src="%s" />' % obj.icon.url
icon_tag.short_description = 'Icon'
icon_tag.allow_tags = True

И добавить в ридонли:
readonly_fields = ('icon_tag',)

Миллион же ответов в инете гуглится. Я чаще всего в таких случаях (т.е. во внешних каких-то более-менее повторно используемых скриптах) тупо выношу токен в основную страницу, потом использую просто как JS-переменную: dark-barker.blogspot.ru/2013/10/django-csrftoken-a...

trigger("click") на самом деле просто стреляет клик-эвент.
Используйте .click().

$('#new a')[0].click();

вуаля

from xml.dom.minidom import *

xml = parse('document.xml')
name = xml.getElementsByTagName('name')

for node in name:
	print node.childNodes[0].nodeValue