Проблемы в библиотеке форм Django на примере поля ввода телефонов

[@Webchemist]

На самом деле многое можно упростить:

1. python-phonenumbers
2. The “local flavor” add-ons

[@MechanisM]

Кстати, в версии Django 1.5 убрали localflavor из Django и перенесли в отдельные репозитории. Например для россии тут. Чтобы ими пользоваться придется их дополнительно устанавливать для каждой страны.

[@MechanisM]

На самом деле вчера не успел отредактировать и уточнить что не убрали а начали процесс по переносу. «localflavor» еще там, но вываливается Deprecation Warning что нужно пользовать django-localflavor-*. В более поздних версиях совсем уберут.

[@BasicWolf]

Спасибо за статью. Небольшое примечание к стилистике:

if not phone:

->

if phone is None:

то же самое с if not value ...

[@homm]

Это же разные проверки. В данном случае все верно.

[@BasicWolf]

Вот уж не согласен. Вторая строка дзен Python: «Explicit is better than implicit.». В Python not X может означать всё что угодно, например:

х = 0 
not x       # тут всё просто
>>> True

x = ""
not x       # а здесь уже работает len(x)
>>> True

х = []
not x       # и здесь
>>> True

x = {}
not x      # то же самое
>>> True

x = None 
not x       # а вот так писать - прямая дорога в Питоний ад. 
>>> True

Я в своё время получил много головной, ожидая в функции строковый аргумент такого вида:

def f(s = None):
    if not s:
        print 's is None'

Проблемы начинались тогда, когда s == "".

[@homm]

Вы не согласны с чем? С тем что not и is None — разные проверки, которые дают разный результат? Откуда там None возмется?

[@BasicWolf]

Да, с None я погорячился. Но тем не менее, при беглом просмотре кода, phone != '' мне скажет гораздо больше, чем not phone. При not phone я предполагаю, что phone содержит булевое значение.

[@zzeus]

«Я использую инпут для одной строки, хочу туда писать много строк. Джанга не удобна».

Офигено. Вам дают отличные инструменты для работы с подобными задачами FormSet и InlineFormSet, почему их не юзаете?

[@warsoul]

Да нет же, строка одна насколько я понял… Я вот только не понимаю чем автору не угодило:
1. хранить в базе готовые отформатированные номера
2. отформатировать номер ровно 1 раз — при получении его от юзера (ну будет он в форме по новому выводится — дак и хрен с ним).

[@homm]

Если хранить отформатированные номера, то для отправки на них смс и для ссылок href=«tel:xxx» придется форматирование вырезать.

[@warsoul]

Ну а так приходится его добавлять при выводе. Какая разница? Вам принципиально надо было шишку на ровном месте набить? Поздравляю — Вы это сделали.

[@homm]

Разница в том, что в базе данных должны храниться данные.

[@homm]

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

[@andrewshkovskii]

Ну так ставьте фокус автоматом, после нажатия на «плюсик».Да и потом, какая надобность ДВА телефона указывать в ОДНОМ поле? Обычная практика — мобильный и стационарный номер.
Какой же ширины поле должно быть? А если не большой ширины, то что бы проверить то, что пользователь ввел — надо курсор двигать влево-вправо? Тоже не очень удобно.

[@homm]

Я не знаю что за обычная практика. В моем случае пользователь может указать нужное ему кол-во номеров, по которым ему могут позвонить клиенты. Домашних или рабочих номеров там нет. Тем не менее, большинство пользователей указывают один номер и второе поле и плюсик только усложняют форму.

[@zzeus]

Ну добавляйте поля по клику пользователя на пробел, запятую и т.д. В чем проблема?

[@homm]

И где вы такое видели? И как это будет работать без js? И если нажать бекспейс в пустом поле, поле нужно убрать (пользователь удаляет виртуальную запятую, которую не видит)? И в чем будет отличие от .split(",") на сервере и от одного поля для пользователя?

Придумываете уже какой-то бред, лишь бы доказать первоначальный тезис, что я сделал что-то не так.

[@zzeus]

Без JS стандартный метод работы с Formset, всегда пара свободных полей дополнительно.

Вы действительно делает что-то не так )

Много телефонов, к одной модели. Это однозначно FK (если не M2M, зависит от данных). Зачем запихивать данные, которые должны храниться как FK в модель через CharField? Ошибка в структуре хранения данных.

[@homm]

> однозначно
> которые должны
> ошибка
Я так не считаю.

[@student100500]

Согласен с тем, что в модели FK на телефонный номер, а в шаблоне формсет, кстати Вы можете оставить одно поле, если Вам так хочется, и вводить номера через запятую, а по сабмиту вызвать js, который преобразует всё в формсет. Но как по мне — то с плюсиком удобнее (с автофокусом).

[@SKiPP]

вот снипет нашёл, наткнувшись на эту статью http://djangosnippets.org/snippets/2811/