Гибкость макета
Представьте, что вы создаете страницу с большим количеством миниатюр.
DIVs :
Если вы поместите каждую миниатюру в DIV с плавающей точкой влево, возможно, 10 из них поместятся в ряд. Сделайте окно уже, а БАМ - это 6 на ряд, или 2, или сколько угодно.
ТАБЛИЦА:
Вы должны явно сказать, сколько ячеек подряд. Если окно слишком узкое, пользователь должен прокрутить горизонтально.
Ремонтопригодность
Та же ситуация, что и выше. Теперь вы хотите добавить три миниатюры в третий ряд.
DIVs:
Добавьте их. Макет будет автоматически изменен.
ТАБЛИЦА: Вставьте новые ячейки в третий ряд. Упс! Теперь там слишком много предметов. Вырежьте некоторые из этого ряда и поместите их в четвертый ряд. Сейчас там слишком много предметов. Вырежьте часть из этой строки ... (и т. Д.)
( Конечно, если вы генерируете строки и ячейки с помощью серверных сценариев, это, вероятно, не будет проблемой. )
Вы, конечно, можете избежать повторения. Чаще всего вам необходимо передать в качестве аргументов класс формы и имя шаблона для использования, вызываемый объект для обработки очищенных данных при отправке действительной формы и место назначения для перенаправления после такой обработки; Кроме того, вам понадобится небольшой дополнительный код для однократного вызова класса формы, создания связанной или несвязанной формы и правильной работы с ней. То есть:
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})
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.
Стандартный способ обработки форм смешивает две задачи: представление формы для редактирования и обработку результатов. Вы можете разбить это на два метода, что приведет к некоторому дублированию в виде идентичных вызовов render_to_response (). К тому времени, когда вы его отредактируете, вы можете получить что-то менее читабельное, чем форма с одним методом выше.
Когда я смотрю на шаблонный метод, я не вижу дублирования. Два использования ContactForm () совершенно разные. Мне кажется, что два условных оператора достаточно четко показывают переходы между состояниями, связанные с обработкой формы (представьте пустую форму,
Я так устал от этого, что написал свои собственные общие представления, чтобы справиться с этим. В процессе я обнаружил, что django уже имеет недостаточно документированные общие представления для обработки форм. Они являются довольно прямыми аналогами задокументированных общих представлений, но принимают формы и в основном следуют тому же шаблону, который вы использовали в своем примере. В конце концов, я нашел их слишком негибкими и глупыми для моего использования (мне не нужно представление create_or_update, я не хочу рассматривать эти два действия по отдельности.)
Изменить: вам не понравился ответ Фрагсворта, который указывает на то же самое, о чем я говорю, я полагаю, вам тоже не понравится моя. Вот пример того, как это работает.
# in urls.py
urlpatterns += patterns("",
(u'^...$', 'django.views.generic.create_update.update', {
'form_class': ContactForm })
)
ContactForm
должен иметь метод save ()
, и именно здесь идет ваша логика обработки формы.
Можно написать функцию, которая обрабатывает условные выражения для всех форм. Вы можете сделать это, передав функцию, специфичную для этой формы, после 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 из вашего представления. Обратите внимание, что это не проверено и может содержать ошибки.
Django provides several generic views for creating, editing, and deleting objects. Perhaps you could try these.
Вы можете обойти модуль форм django и просто сделать это по старинке, вы получите большую гибкость без особых потерь. ИМХО.
Последний раз я смотрел формы django довольно давно , Я не знаю, изменилось ли что-то, но, например, это действительно не позволяет вам создать форму в стиле ajax; по крайней мере, нелегко.