Установка владельца объекта с помощью общего представления create_object в django

Question

Можно ли использовать представление create_object для создания нового объекта и автоматически назначить request.user в качестве внешнего ключа?

P.E:

class Post(models.Model):
    text = models.TextField()
    author = models.ForeignKey(User)

Я хочу использовать create_object и заполнить автора request.user.

Answer 1

Вы можете рассмотреть вопрос о закрытии.

from django.forms import ModelForm
from django.views.generic.create_update import create_object, update_object

def make_foo_form(request):
    class FooForm(ModelForm):
        class Meta:
            model = Foo
            fields = ['foo', 'bar']

        def save(self, commit=True):
            f = super(FooForm, self).save(commit=False)
            if not f.pk: f.user = request.user
            if commit: f.save()
            return f

    return FooForm

def create_foo(request):
    FooForm = make_foo_form(request)
    return create_object(form_class=FooForm)

Здесь есть некоторая неэффективность, так как вам нужно создавать объект ModelForm для каждого запроса, но он позволяет внедрить функциональность в общее представление.

Вам необходимо решить, стоит ли добавленная сложность для создания формы сохранять простоту на стороне представления.

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

def update_foo(request, object_id):
    FooForm = make_foo_form(request)
    return update_object(form_class=FooForm, object_id=object_id)

Очевидно, что вы можете использовать этот подход и для более сложных случаев.

Answer 2

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

Написать контекстный процессор:

from django.views.generic.create_update import get_model_and_form_class
def form_user_default(request):
    if request.method == 'GET':
        model, custom_form = get_model_and_form_class(Post,None)
        custom_form.author = request.user
        return {'form':custom_form}
    else: return {}

Что это будет делать, так это переопределить объект формы, который create_update передает в шаблон. Технически, это делает воссоздание формы после того, как это сделал вид по умолчанию.

Тогда в вашем url conf:

url(r'pattern_to_match', 'django.views.generic.create_update.create_object', kwargs={'context_processors':form_user_default})

Опять же, мне пришлось углубиться в исходный код, чтобы понять, как это сделать. Возможно, лучше всего написать собственный вид (но включить как можно больше пользовательских объектов Django). Для этого нет простого способа «по умолчанию», потому что в парадигме django формы более тесно связаны со слоем модели, чем с представлениями, и только представления знают объект запроса.

Answer 3

Если пользователь аутентифицирован, его пользовательский объект является request.user объектом.

Я не знаком с create_object ... Я все еще начинающий в django и только начал свой первый настоящий проект с ним.

Обратите внимание, что вы должны убедиться, что пользователь вошел в систему, прежде чем использовать это. Это можно сделать с помощью request.user.is_authenticated().

Answer 4

Я бы предложил сделать обертку для create_object, как предлагает этот автор http://www.b -list.org / блог / 2006 / ноября / 16 / Джанго-советы-получить большинство-из-родового вид / в представлении у вас будет доступ к информации о пользователе. После этого вам нужно будет использовать extra_context, чтобы передать пользователя в шаблон. Наконец в шаблоне вы можете добавить скрытое поле с информацией о пользователе. Я не пробовал это, но я думал об этом в течение достаточно долгого времени. Надеюсь, что это решение подходит вам! ;) ура!

Answer 5

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

По этой причине я уже использую свои собственные базовые представления на основе классов.