Отнаследовать все вьюхи от одной?

Хм. Сомневаюсь, что это хорошая идея. Я использую классические function-based views. Следовательно, добавить экшена ко вьюхам можно только с помощью декорирования. А это попахивает костылями.

Я использую классические function-based views.

Ты хочешь избежать дублирования функционала, но при этом не хочешь вызывать один и тот же метод из всех мест. Это решается наследованием, но ООП ты тоже не хочешь.

Да. В проекте не используются CBV.

Решил просто вынести функционал обработки формы ввода в отдельную функцию, принимающую в качестве аргументов - request а возвращающую объект from.

Затем просто добавляю результат в контекст каждой и вьюх. Это сильный костыль)?

збс упрлс

Отдельный view для логина чем не катит?

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

Думаю, параметр next в query string поможыд.

UPD: Как-то так.

<form action="{% url "login" %}?next={{ current_url }}" method="POST">

Стоит попробовать, ящетаю.

http://chriskief.com/2012/12/30/django-class-based-views-with-multiple-forms/

появляется в результате нажатия на некоторую кнопку (скажем, в хедере сайта), а хедер наследуется всеми страницами.

Раз у тебя хедер наследуется всеми страницами, то все вью, которые рендерят эти страницы, должны уметь рендерить форму и знать о ней (вставлять csrf токен, к примеру, в форму). Следовательно, каждая вьюшка должна иметь код создания формы. А это достигается наследованием. Класс вью для этого и созданы. Вообще, конечно, такая архитектура - в любой странице форма - несколько гемморна и, с моей точки зрения, не правильна. Желательно делать отдельную страницу для логина, отдельную для поиска, отдельную для ошибок и т.д. Сам я тоже так кодил - на одной странице были и поиск и логин, но лучше не смешивать (а если смешивать, то давать имя сабмит кнопке и/или разводить форму в разные url).

http://stackoverflow.com/questions/2734055/putting-a-django-login-form-on-eve...

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

0) Создаем экземпляр класса Form:

class LoginForm(forms.Form):
    username = forms.CharField(
        label=u'Имя пользователя', min_length=3, max_length=32,
        widget=forms.TextInput(attrs={'class': 'form-control'})
    )
    password = forms.CharField(
        label=u'Пароль', min_length=6, max_length=32,
        widget=forms.PasswordInput(attrs={'class': 'form-control'}),
    )

1) Определяем шаблон формы:

<form action="{% url "accounts:login" %}?next={{ current_url }}" method="POST">
  {% csrf_token %}
  <div class="form-group">
    {{ form.username.errors }}
    <label for="id_username">Имя пользователя:</label>
    {{ form.username }}
  </div>
  <div class="form-group">
    {{ form.password.errors }}
    <label for="id_password">Пароль:</label>
    {{ form.password }}
  </div>
  <div class="checkbox">
    <label>
      <input type="checkbox"> Запомнить
    </label>
  </div>
  <button type="submit" class="btn btn-default">Войти</button>
</form>

2) Ренедрим фому как inclusion_tag:

def login_form(request_path):
    return {"form": LoginForm(), "current_url": request_path}

register.inclusion_tag("units/forms/form_signin.djhtml")(login_form)

3) Обрабатываем форму

def auth_login(request):
    """
    :param request:
    :return:
    """
    if request.method == "POST":
        form = LoginForm(request.POST)
        if form.is_valid():
            username = form.cleaned_data['username']
            password = form.cleaned_data['password']
            user = authenticate(username=username, password=password)
            if user is not None:
                if user.is_active:
                    login(request, user)
                    return HttpResponseRedirect(request.GET.get("next"))
            else:
                return HttpResponse(u"Ошибка авторизации!")
    return HttpResponseRedirect(request.GET.get("next"))

Но, как вы понимаете, валидация работать не будет(. К сожалению, я не нашел адекватного способа базовыми средствами решить данную проблему. Буду писать отдельные шаблоны - тогда все встанет на свои места).

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

Это я понимаю. Просто не нравится мне, что нужно добавлять в контекст каждой вьюхи рендер формы. Понимаете?

если форма находится в модальном окне

то у клиента гарантировано есть Javascript. Следовательно, можно делать AJAX-формы, которые будет валидировать Django Rest Framework и код обработки формы будет ровно в одном месте. В чём проблемы?

Впрочем, и с классическими формами: action формы — на единственный вид с проверкой, который по успешной валидации отправляет назад. По неуспешной — можно придумать, что делать, например, добавлять в GET URL возврата, если осторожно (можно случайно сделать себе XSS).

Для нежелающих в ООП и контекстные процессоры

# функция для формирования общего контекста всех обычных вьюх
def common_context():
    context = {
        ...
        'login_form': LoginForm()
    }
    return context

# обычная вьюха, перед ответом контекст дополняется общим
dev some_view(request):
    ...
    context = context.update(common_context())
    return render(request, template, context)

А post-запрос на action url формы обрабатывать отдельной вьюхой

Для нежелающих в ООП и контекстные процессоры

Не учи детей плохому.

Правильнее, наверное, вот так: http://stackoverflow.com/a/3124885

На самой странице рендерить форму через LoginForm не надо, этим пусть занимается login view, на остальных страницах достаточно прописать html.