0

Я добавил поле «пользователь» ко всем моим моделям. Когда пользователь создает объект, я хочу, чтобы прикрепить их ID через внешний ключПреобразование функции django общий вид в общий общий класс

user = models.ForeignKey(User) 

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

У меня есть одна функция, которая обрабатывает все редактирование объектов, будь то создание или обновление:

@login_required 
def edit_item(request, modelname, submodelname=None, slug=None, id=None): 
    # Get parameter "next" to determine where to send user after object is created or updated 

    # Define which template to use 

    # Determine whether user is converting an object to another type 

    # Determine which form_class to use based on modelname and whether user is converting or not 

    # Redirect user if slug and id are not both correct 

    # Abort if user hit cancel instead of submit 

    # If object exists (slug and id are defined): 
     # Update_object with form_class, object_id, template_name, post_save_redirect, and extra_context 
    # Else 
     # Create_object with form_class, template_name, post_save_redirect, and extra_context 

В рамках общей точки зрения на основе классов, как/где/когда я выполняю некоторые из этих вычислений (логика вокруг определения шаблон или form_class на основе критериев)? Я смущен, потому что документы, похоже, идут прямо к определениям:

class ContactView(FormView): 
    template_name = 'contact.html' 
    form_class = ContactForm 
    success_url = '/thanks/' 

Могу я просто бросить туда логику?

class ContactView(FormView): 
    A = 1 + 2 
    if A == 3: 
     template_name = 'contact.html' 
    else: 
     template_name = 'contact_two.html' 
    form_class = ContactForm 
    success_url = '/thanks/' 

И как бы/я должен изменить свою логику, чтобы переадресовать в использовании CreateView или UpdateView против того, что я сделал здесь, в использовании create_object или update_object в одной и той же функции в зависимости от того, определяются пробкового/идентификатор?

+2

Зачем конвертировать функцию Django? Общий вид не так удобен. Один большой минус - ** наследование ** вместо композиции. Более практично создавать свои собственные представления на основе классов или использовать функцию просмотра. Общие представления BTW устарели в новейших версиях Django. – sergzach

+0

Вы предлагаете создать представление класса, которое не основано на общих представлениях на основе классов? Я знаю, что функция create/update_object на основе функций устарела, но я думал, что их заменяют общие представления классов. –

+0

Извините меня за дезинформацию. В любом случае, достаточно подумайте, прежде чем использовать общие представления на основе классов. Иногда бывает больно, если вы хотите добавить новый класс в промежуточную позицию цепочки наследования. Если у одного класса есть несколько детей, и у одного ребенка должна быть функция нового промежуточного класса, а у другого ребенка не должна быть функция, требующая рефакторинга. Вы должны обрабатывать общие части в нескольких функциях. В моей практике это становится немного негибкой структурой. Посмотрите там: http://dpaste.com/hold/823122/ – sergzach

ответ

1

Общие представления на основе классов имеют методы, которые используются для требуемых задач. Например, для формы, которая создает объект, вы используете CreateView, и для определения какой формы используется переопределить метод get_form_class().

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

Смежные вопросы