Comments 17
Тут бы лучше вообще сделать пример и выложить код куда-нибудь. А то слишком много сорцов. Да и пример мне показался сложноватым.
Присовокупите к своему сообщению ссылку на автоматический проверяльщик PEP8, будем признательны.
pypi.python.org/pypi/pep8 вроде оно
спасибо, будем исправляться.
> Но это в корне не верно, потому что при таком наследовании все функции StudentForm
> перетрутся ContractForm, потому что они идентичны по названиям и параметрам
> (т.к наследованны от одного класса forms.Form).
Что?
> перетрутся ContractForm, потому что они идентичны по названиям и параметрам
> (т.к наследованны от одного класса forms.Form).
Что?
А почему для «Пол» вы не сделали CHOICES?
Разве такой большой и неопределенный выбор?
Разве такой большой и неопределенный выбор?
В современном обществе — да.
исправился.
Ваш «SEX_CHOICES» лучше прописать где-нить один раз и ипортировать оттуда. Чем куча «SEX_CHOICES» в разных файлах(в вашем случае в models.py и в forms.py). Что если кому-то надо срочно добавить что-то или изменить? Придется искать во всех файлах где вы накопипастили этот «SEX_CHOICES» да и не DRY получается.
По заголовку топика думал речь пойдет о действительно сложных формах, а не о визарде. Давайте представим ситуацию, что вам надо сделать то же самое, но ограничиться одной страницей. Чтобы долго не филосовствовать зачем это может быть нужно, таковы требования заказчика. В результате нам нужно показать на одной странице три формы и ограничиться одним HTTP запросом. Есть несколько вариантов и в текущей версии джанги с ними не все просто.
1) Django-way — это сделать одну мега-форму, объединяющую все три. Если эти 3 формы больше ни где не используются, то вполне вариант. Если они есть где-то еще, то это может усложнить поддержку системы. Ну и еще копипаст — это плохо
2) Мы делаем вьюху, которая умеет работать с нужным количеством форм. Тут все достаточно просто, но операция рутиная — generic views для этого нет. Почему-то нету generic views даже для редактирования объекта вместе со связанными объектами.
3) Делаем прокси-объект, который содержит в себе все нужные формы и имеет интерфейсы, аналогичные формам джанги. Здесь требуется некоторый опыт работы с джанго-формами либо желание разобраться в том как они работают. Самый универсальный вариант, но свободной реализации такого не видел.
Если извесные разработки по 2 и 3 случаю, и кто-то поделится ссылками, буду благодарен.
1) Django-way — это сделать одну мега-форму, объединяющую все три. Если эти 3 формы больше ни где не используются, то вполне вариант. Если они есть где-то еще, то это может усложнить поддержку системы. Ну и еще копипаст — это плохо
2) Мы делаем вьюху, которая умеет работать с нужным количеством форм. Тут все достаточно просто, но операция рутиная — generic views для этого нет. Почему-то нету generic views даже для редактирования объекта вместе со связанными объектами.
3) Делаем прокси-объект, который содержит в себе все нужные формы и имеет интерфейсы, аналогичные формам джанги. Здесь требуется некоторый опыт работы с джанго-формами либо желание разобраться в том как они работают. Самый универсальный вариант, но свободной реализации такого не видел.
Если извесные разработки по 2 и 3 случаю, и кто-то поделится ссылками, буду благодарен.
В wtforms это решается парой строк кода. Пусть StudentFrom — класс формы одного студента, тогда ListField(FormField(StudentForm)) — поле, содержащее список форм студентов.
Спасибо за пост,
Sign up to leave a comment.
Сложные формы в Django