Я добавил поле «пользователь» ко всем моим моделям. Когда пользователь создает объект, я хочу, чтобы прикрепить их 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 в одной и той же функции в зависимости от того, определяются пробкового/идентификатор?
Зачем конвертировать функцию Django? Общий вид не так удобен. Один большой минус - ** наследование ** вместо композиции. Более практично создавать свои собственные представления на основе классов или использовать функцию просмотра. Общие представления BTW устарели в новейших версиях Django. – sergzach
Вы предлагаете создать представление класса, которое не основано на общих представлениях на основе классов? Я знаю, что функция create/update_object на основе функций устарела, но я думал, что их заменяют общие представления классов. –
Извините меня за дезинформацию. В любом случае, достаточно подумайте, прежде чем использовать общие представления на основе классов. Иногда бывает больно, если вы хотите добавить новый класс в промежуточную позицию цепочки наследования. Если у одного класса есть несколько детей, и у одного ребенка должна быть функция нового промежуточного класса, а у другого ребенка не должна быть функция, требующая рефакторинга. Вы должны обрабатывать общие части в нескольких функциях. В моей практике это становится немного негибкой структурой. Посмотрите там: http://dpaste.com/hold/823122/ – sergzach