marazm 20 ноя 2007 в 22:09

django.newforms: Используем.

3 мин

2.4K

Комментарии 35

Uznick 20 ноя 2007 в 23:40

Я вот сильно жду newforms-admin и надеюсь что тогда можно будет спокойно в админку добавлять свои кастомные элементы форм.

ESQUELETO 21 ноя 2007 в 00:08

А я уже давно использую newforms-admin.
SVN: http://code.djangoproject.com/svn/django/branches/newforms-admin
Скоро запускаю рискованный проект на этой ветке :-)

FAQ от Llama, который знает newforms-admin очень хорошо: http://code.djangoproject.com/wiki/NewformsHOWTO
Так же вы можете его найти на официальном irc-канале #django в сети FreeNode :)

Uznick 21 ноя 2007 в 00:09

О, спасибо.

С тех пор как я смотел newforms-admin в последний раз, дело продвинулось :)

ESQUELETO 21 ноя 2007 в 00:17

Они довольно часто коммитят в этот бранч...
Они называют oldforms и oldforms-admin «horrible» :)

marazm 21 ноя 2007 в 07:00

Могли бы написать по поводу этой штуке топик. Я, например, об этой ветке первый раз слышу.

marazm 21 ноя 2007 в 07:01

Очепяточка: штуки :D

ignatov 21 ноя 2007 в 00:43

Спасибо. Только ошибки/опечатки поправьте, пожалуйста.

zencd 21 ноя 2007 в 04:07

да, в слове «млять» с ошибка

fxposter 21 ноя 2007 в 07:01

Такое впечатление, что документацию к Django newforms автор не читал.

> class SelectFromModel(forms.Field):
Круто написал, все ок. Только есть ChoiceField.

> class TagField(forms.CharField):
Подобный clean - это уровень приложения, а никак не формы.

marazm 21 ноя 2007 в 07:06

Не нравится что наследую от Field? Это только для гибкости, не более. Потому как от подобного (select) ввода собираюсь отказаться. Но по сути, я его и реализовал (и помню, даже пробовал ChoiceField).

На счёт TagField, сложный вопрос. Мне понадобится ещё как минимум 10 таких полей на весь сайт впихнуть. Всёравно придётся выносить код в отдельный метод, а в поле он как-то в тему получается.

fxposter 21 ноя 2007 в 07:16

1. Никакой гибкостью в отличии от использования того же ChoiceField там, на самом деле, и не пахнет. ;)

2. Ну, куда писать код - это тебе решать. Но для начала советую все же перечитать доку джанговскую. А насчет clean - "Each Field in a Form class is responsible not only for validating data, but also for “cleaning” it — normalizing it to a consistent format".

fxposter 21 ноя 2007 в 07:18

Т.е. clean - это НЕ обработчик значения поля, этим в джанге view'ы занимаются. Так что советую задуматься.

marazm 21 ноя 2007 в 07:24

1. Ну мб :) Почему-то решил не завязываться на Choice, вот хз почему)

2. Как раз для normalizing it to a consistent format и делаю clean. Т.е. строка -> Набор значений. Опять же, в Django есть поле выполняющее подобную функцию, если мне не изменяет память

P.S> Вообще, я это делал достаточно давно и причины, по которым я сделал некоторые вещи, не совсем помню.

marazm 21 ноя 2007 в 07:28

Я не уверен, но мб претензии к тому, что я зря вообще писал загрузку данных и это всё уже есть в ChoiceField? Я рыл сырцы, но ничего не нашёл.

fxposter 21 ноя 2007 в 07:32

http://www.djangoproject.com/documentati…

ctrl+f - вбиваешь "choice", читаешь.

marazm 21 ноя 2007 в 07:42

Там только о доп. параметре. Как туда можно забить значения на автомате? Т.е. чтоб было проще чем выше (учитывая что мне нужно будет ещё как минимум 10 полей для city, metrostation (кстати, ещё к этому полю есть виджет) и ещё немного раз category.

fxposter 21 ноя 2007 в 07:33

2. Угу, и добавление в таблицу - тоже нормализация? :)

marazm 21 ноя 2007 в 07:37

Да.Один хрен их добавлять придётся. DRY, бля

fxposter 21 ноя 2007 в 07:42

try:
dbtag = Tag.objects.get(title=tag)
except:
dbtag = Tag(title=tag)
dbtag.save()

Написать эти 4 строки несколько раз - это лучше, чем перековеркивать смысл работы приложения. ;)

PS. А вообще - можно в функцию это оформить.

marazm 21 ноя 2007 в 07:44

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

И считаю, для простоты дальнейшей работы приемлемо коверкать смысл :)

fxposter 21 ноя 2007 в 07:52

Эх...
Учишь вас, учишь. А потом сидишь и материшься, когда приходится код дописывать. :(

1. Читай про MVC
2. Форма не должна менять модель, понятно почему? :)
3. Твой пример пишется в одну строку, так что ни в какую функцию его выносить не нужно:
Tag.objects.get_or_create(title=tag)

marazm 21 ноя 2007 в 07:59

1. Читал, видел, делал
2. Не соглашусь! Вот виджет, да, это View, а Field это контроллер всяко разно!
3. Да, это я знаю. Старая привычка делать через исключения :) Сейчас уже исправляюсь. Но всё же функциональность не только в добавлении тега (тем более одного) в БД, там ещё разделение тегов, например.

fxposter 21 ноя 2007 в 08:05

"django.newforms is intended to handle HTML form display, data processing (validation) and redisplay."

Заметь - "validation". В твоем случае, validation - это разбить на теги, т.е:

def clean(self, value):

    return [tag.strip().lower() for tag in value.split(',')]

marazm 21 ноя 2007 в 08:14

Признаюсь, я очень упёртый человек па жизни :D

def clean(self, value):

    return [Tag.objects.get_or_create(

title=tag.strip().lower() )for tag in value.split(',')]

fxposter 21 ноя 2007 в 08:16

Это не нормализация. :)

marazm 21 ноя 2007 в 08:03

3 Поправил и + в карму. :) Пусть всёже, кому надо учатся правильно делать.

fxposter 21 ноя 2007 в 08:07

:))

ESQUELETO 21 ноя 2007 в 10:42

А еще можно написать вот так :)
newTag, created = Tag.objects.get_or_create(title=tag)
Если есть такой тэг, newTag будет ссылкой на него, а created — False.
Если нет, то такой тэг создастся, newTag будет ссылкой на него, а created — True.

Уже одна строка :)

marazm 21 ноя 2007 в 11:21

Уже и так метод в одну строку записали :)

ESQUELETO 21 ноя 2007 в 15:41

Да, просмотрел. Но, думаю, не беда, что описал как оно работает. А вернее, что возвращает :)

krylatij 21 ноя 2007 в 10:14

А почему для тэгов не воспользоваться готовым http://code.google.com/p/django-tagging/…
И по поводу категории я не понял, почему не воспользоваться models.ForeignKey ? Там же уже реализован и Select и валидация.