Альтернатива шаблону обработки формы django?

Гибкость макета
Представьте, что вы создаете страницу с большим количеством миниатюр.
DIVs :
Если вы поместите каждую миниатюру в DIV с плавающей точкой влево, возможно, 10 из них поместятся в ряд. Сделайте окно уже, а БАМ - это 6 на ряд, или 2, или сколько угодно.
ТАБЛИЦА:
Вы должны явно сказать, сколько ячеек подряд. Если окно слишком узкое, пользователь должен прокрутить горизонтально.

Ремонтопригодность
Та же ситуация, что и выше. Теперь вы хотите добавить три миниатюры в третий ряд.
DIVs:
Добавьте их. Макет будет автоматически изменен.
ТАБЛИЦА: Вставьте новые ячейки в третий ряд. Упс! Теперь там слишком много предметов. Вырежьте некоторые из этого ряда и поместите их в четвертый ряд. Сейчас там слишком много предметов. Вырежьте часть из этой строки ... (и т. Д.)
( Конечно, если вы генерируете строки и ячейки с помощью серверных сценариев, это, вероятно, не будет проблемой. )

7
задан John 18 July 2009 в 21:55
поделиться

7 ответов

Вы, конечно, можете избежать повторения. Чаще всего вам необходимо передать в качестве аргументов класс формы и имя шаблона для использования, вызываемый объект для обработки очищенных данных при отправке действительной формы и место назначения для перенаправления после такой обработки; Кроме того, вам понадобится небольшой дополнительный код для однократного вызова класса формы, создания связанной или несвязанной формы и правильной работы с ней. То есть:

def process_any_form(request, 
                     form_class, template_file_name,
                     process_data_callable, redirect_destination):

    form = form_class(request.POST if request.method == 'POST' else None)

    if form.is_bound and form.is_valid():
        process_data_callable(form.cleaned_data)
        return HttpResponseRedirect(redirect_destination)

    return render_to_response(template_file_name, {'form': form})
10
ответ дан 6 December 2019 в 09:21
поделиться

Alex's generic handler beat me to it, but FWIW we tend toward a less-generic version of his suggestion:

def contact(request):
    post_data = request.POST if request.method == 'POST' else None
    form = ContactForm(post_data)
    if request.method == 'POST':
        # perform normal validation checking, etc

    return render_to_response('contact.html', {
        'form': form,
         })

If post_data is None, then the form is instantiated as being unbounded. Otherwise, bound processing continues as normal. It avoids a duplicated construction of ContactForm, but I agree with Dave's answer that the duplicate construction doesn't bother me as being a duplicate precisely because the construction parameters are different.

1
ответ дан 6 December 2019 в 09:21
поделиться

Стандартный способ обработки форм смешивает две задачи: представление формы для редактирования и обработку результатов. Вы можете разбить это на два метода, что приведет к некоторому дублированию в виде идентичных вызовов render_to_response (). К тому времени, когда вы его отредактируете, вы можете получить что-то менее читабельное, чем форма с одним методом выше.

Когда я смотрю на шаблонный метод, я не вижу дублирования. Два использования ContactForm () совершенно разные. Мне кажется, что два условных оператора достаточно четко показывают переходы между состояниями, связанные с обработкой формы (представьте пустую форму,

2
ответ дан 6 December 2019 в 09:21
поделиться

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

Изменить: вам не понравился ответ Фрагсворта, который указывает на то же самое, о чем я говорю, я полагаю, вам тоже не понравится моя. Вот пример того, как это работает.

# in urls.py
urlpatterns += patterns("", 
    (u'^...$', 'django.views.generic.create_update.update', {
        'form_class': ContactForm })
)

ContactForm должен иметь метод save () , и именно здесь идет ваша логика обработки формы.

1
ответ дан 6 December 2019 в 09:21
поделиться

Можно написать функцию, которая обрабатывает условные выражения для всех форм. Вы можете сделать это, передав функцию, специфичную для этой формы, после is_valid, например:

def FormHandler(request, CleaningFunction, redirecturl):
    if request.method = 'POST':
        if request.method == 'POST': # If the form has been submitted...
            form = ContactForm(request.POST) # A form bound to the POST data
            if form.is_valid(): # All validation rules pass
                CleaningFunction(form) # Process the data in form.cleaned_data
                return HttpResponseRedirect('/thanks/') # Redirect after POST
     else:
         form = ContactForm() # An unbound form
     return form

Затем вы должны вызвать FormHandler из вашего представления. Обратите внимание, что это не проверено и может содержать ошибки.

0
ответ дан 6 December 2019 в 09:21
поделиться

Django provides several generic views for creating, editing, and deleting objects. Perhaps you could try these.

0
ответ дан 6 December 2019 в 09:21
поделиться

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

Последний раз я смотрел формы django довольно давно , Я не знаю, изменилось ли что-то, но, например, это действительно не позволяет вам создать форму в стиле ajax; по крайней мере, нелегко.

0
ответ дан 6 December 2019 в 09:21
поделиться
Другие вопросы по тегам:

Похожие вопросы: