marazmiki

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

Упростите жизнь себе и своим пользователям: используйте аутентификацию через социальные сети. В решениях типа ULogin или Loginza уже собраны десятки способов идентификации пользователя. Хоть один, да подойдёт :-)

Проблема борьбы со спамом автоматически ложится на плечи стороннего сервиса, а пользователям не придётся запоминать новый пароль.

И с джангой они отлично дружат.

Проще всего сделать отдельную страничку, на которой будут обе формы. Только вывод, никакой обработки.

Сперва написать вьюху:

from django.shortcuts import render
def all_in_one(request):
    return render('reg_and_login.html', {
        'login_form': LoginForm(),
        'register_form': RegistrationForm()
    })

Затем добавить её к тем, что уже объявлены. Особое внимание уделить тому, чтобы регистрация и вход ввели на разные урлы:

url(r'^$', 'all_in_one'), # Добавили
url(r'^registration/$', 'PersonRegistration', name = 'register-form'), # Изменили
url(r'^login$', 'LoginRequest', name = 'login-form'),  # Изменили

И сделать шаблон (этот код взят из ответа larikov):

<!-- reg_and_login.html -->
<form action="{% url login-form %}" method="post">
    {{ login_form }}
</form>

<form action="{% url register-form %}" method="post">
     {{ register_form }}
</form>

Дикость какая-то.

Зачем обрабатывать регистрацию и вход в одной вьюхе-то? Ладно, можно на одной странице обе формы вывести, если совсем неймётся. Но обрабатывать!..

Начиная с версии 1.3, в Джанге по умолчанию используется django.contrib.staticfiles — отличное приложение, упрощающее работу со статикой проекта.

В режиме разработки, то есть когда runserver запускаете, это приложение ловит все запросы, которые начинаются на STATIC_URL и ищет запрошенный файл без этого префикса в папке static каждого приложения в INSTALLED_APPS.

Не вдаваясь в подробности, которые прекрасно описаны в манулае, могу вот что посоветовать: сделайте приложение с именем, например, sitemedia, подключите его в INSTALLED_APPS, внутри этого приложения создайте директорию static и поскидайте всю статику туда.

Обратите внимание только: статику, а не медиа! Это разные директории для разных целей.

И ещё: в 1.4 ADMIN_MEDIA_PREFIX не используется.

Шаблоны можно не трогать, всё уже придумано до нас:

class MyAppAdmin(admin.ModelAdmin):
    ...
    class Meta:
        js = ['/static/my_app/js/sum_fields.js']

Возможность выделить в админке Django несколько элементов, и где-то показать результат обработки данных выделеных элементов (ну если проще — показать сумму из полей всех выделенных элементов).
Видится что тут как-то через Actions надо выходить, но не понятно куда можно было бы вывести результат суммирования.

На всякий случай уточню, что под actions обычно понимается работа с выбранными объектами на серверной стороне. Это значит, что когда Вы выбираете список моделей, нужное действие и жмёте кнопочку, делается запрос на сервер и отрабатывает функция такого вида:

def action_name(request, queryset):
    """
    В queryset попадут выбранные модели.
    """

Если эта функция возвращает None, происходит редирект на ту же страницу со списком моделей. Но она может вернуть и объект HttpResponse, а значит, и работать будет как обычная вьюшка. В частности, в этой функции можно посчитать искомую сумму и показать её на отдельной странице (подробнее об admin actions).

Чисто субъективно, способ не очень подходит: это ведь неудобно — сперва выбирать нужные модели, потом выбирать действие, потом давить кнопочку, страница перегрузится, выбранные галочки слетят… думаю, лучше делать вычисления на JS. По аналогии со скриптом, который показывает, сколько записей выбрано.

Нужно вывести в админке Django данные из таблицы за определеный период (т.е. от одной даты, до другой). Естественно даты должны водиться пользователем. Сортировка по месяцам в Django есть и так, но вот как и куда присобачить панельку для ввода дат, и последующей фильтрации не ясно.

Написание собственных фильтров в 1.4 реализовано довольно неплохо (пример). Можно создать свой класс фильтра с собственным шаблоном, в котором поля «от» и «до» выводятся дейт-пикерами. Располагаться эта панелька будет в стандартном месте для фильтров (справа, в серой колонке). По-моему, вполне себе решение.

Контекст-процессоры, пожалуй (en, ru)

И я, пожалуй, оставлю тут ссылку на топик смежной тематики

Не советую нормально запускать то что написали: слишком уж много идеологических ошибок.

Во-первых, Вы не проверяете пользовательский ввод. Два примера: у Вас в модели Team уникальный индекс на поле name. Если пользователь введёт в POST-форме имя команды, которое уже существует, вывалится ошибка базы данных. Аналогичная ситуация с User.

Во-вторых, Вы Вы создаёте User, но не создаёте UserProfile. Сам он создаваться не будет, следовательно, вызов user.get_profile() (у Вас, кстати, скобочек не было, отсюда и AttributeError).

В-третьих, Вы пытались в поле внешнего ключа, которое должно принимать объект модели, пытаетесь передать целочисленное значение. Надо было так:

user.get_profile().team = team

Как правильно? Используйте ModelForm. Они возьмут на себя рутинную работу по грамотной валидации данных и будут возвращать сконструированные инстансы моделей.

Хотя конкретно в этом случае ModelForm не очень подойдёт, потому что данные сохраняются в несколько разных моделей. В таких случаях приходится использовать Form и чуть-чуть програмировать, а именно описывать нестандартную логику валидациитам, где это требуется (метод clean_something описывает пользовательскую валидацию поля something, подробности в разделе Form and field validation документации).

Код формы (forms.py) будет примерно таким (писалось экспромтом и не тестировалось, не надо бездумно копипастить):

# -*- coding: utf-8 -*-
from django import forms
from django.contrib.auth.models import User

class RegisterForm(forms.Form):
    username = forms.CharField()
    email    = forms.EmailField()
    password = forms.CharField()
    teamname = forms.CharField()

    def clean_username(self):
        """
        Проверим уникальность юзернейма
        """
        username = self.cleaned_data.get('username')

        if User.objects.filter(username=username).count() > 0:
            raise forms.ValidationError, 'User %s is already exists' % username
        return username

    def clean_team(self):
        """
        Проверим уникальность имени команды
        """
        name = self.cleaned_data.get('teamname')

        if Team.objects.filter(name=name).count() > 0:
            raise forms.ValidationError, 'Team %s is already exists' % name
        return name
    
    def clean(self):
        """
        Подготовка чистых данных для вставки в модель
        """
        data = super(RegisterForm, self).clean()

        data['user'] = User.objects.create_user(
            username = data['username'],
            password = data['password'],
            email    = data['email'],
        )
        data['team'] = Team.objects.create(
            name = data['teamname'],
        )

        return data

А кусок с самой регистрацией в views.py будет выглядеть примерно так:

form = RegisterForm(request.POST or None)
if form.is_valid():
    data = form.cleaned_data
    profile, created = UserProfile.objects.get_or_create(
        user = data['user'], # user - модель, а не строка
        team = data['team'], # team тоже модель
    )

При желании можно инкапсулировать создание UserProfile в классе формы. Это даже правильнее, но в данном случае непринципиально :)

Если я где-то ошибся или непонятно — спрашивайте и добро пожаловать в клуб :)