Комментарии 13
М, хорошая идея завернуть эти автокомплиты в виджет, нам бы тоже так наверное следовало сделать :) Как-то отслеживаете/модифицируете введённые пользователем данные? Что если кто-то сделает город «Мсква»?
ИМХО: а не лучше ли в модели City:
country = ForeignKey('Country', related_name='cities')?
С городами и странами да. Можно подойти с двух сторон: ManyToManyField — одна страна принадлежит множеству городов, ForeignKey — один город принадлежит одной стране.
С другой стороны, если нам необходима связка моделей City и Profile, к примеру, когда пользователь может указать множество городов, в которых он был. Или, как я написал в самом конце, данный подход можно использовать для реализации тегов, когда один тег принадлежит множеству сообщений. В этом подходе ForeignKey уже не подойдет.
Или же вариант, если модель City нам необходимо использовать не только для связки с таблицей Country, но и с другими таблицами. В этом подходе хочется, чтобы модель City была максимально независима от остальной логики проекта.
С другой стороны, если нам необходима связка моделей City и Profile, к примеру, когда пользователь может указать множество городов, в которых он был. Или, как я написал в самом конце, данный подход можно использовать для реализации тегов, когда один тег принадлежит множеству сообщений. В этом подходе ForeignKey уже не подойдет.
Или же вариант, если модель City нам необходимо использовать не только для связки с таблицей Country, но и с другими таблицами. В этом подходе хочется, чтобы модель City была максимально независима от остальной логики проекта.
Мне кажется, что лучше будет не подгружать данные с сервера на лету, а сразу брать все города и грузить в виде json + кешировать. Это будет быстрее для пользователя и меньше будет грузить сервер.
Да, вопрос быстродействия меня тоже волнует и пока что я не определился как лучше. Мельком посмотрел метки на хабре, вроде бы подгружаются по мере ввода пользователем.
И опять же с какой стороны посмотреть, базу городов мы хотя бы примерно можем оценить по объему. А если использовать структуру, бесконечно расширяющуюся, такую как метки на хабрахабр. Не станет ли в определенный момент объем меток критичен для быстродействия?
И опять же с какой стороны посмотреть, базу городов мы хотя бы примерно можем оценить по объему. А если использовать структуру, бесконечно расширяющуюся, такую как метки на хабрахабр. Не станет ли в определенный момент объем меток критичен для быстродействия?
Вам города России нужны или всего мира?
Я не хочу ставить себя в какие-то рамки, поэтому сразу рассчитываю, что города могут быть со всего мира.
gist.github.com/1519751 — России, если гзипом отдавать, то можно прямо в
формсеты
smart_select
django-cities
@media для виджетов
схема бд неудачная, обоснования высосаны из пальца
спасибо что делитесь опытом, многим новичкам будет полезно
«… я в джангобуке читал что регистрацию надо самому реализовывать!...»
плюсанул
smart_select
django-cities
@media для виджетов
схема бд неудачная, обоснования высосаны из пальца
спасибо что делитесь опытом, многим новичкам будет полезно
«… я в джангобуке читал что регистрацию надо самому реализовывать!...»
плюсанул
Я надеюсь вы прочитали моё послесловие? Я использую данный подход не на том примере, что описывается в статье. Код я специально облегчил, чтобы не вводить в заблуждение. Именно поэтому я не стал называть статью «Делаем теги в django» или «Реализация поля город в django». Модели нейтральны, главное — множественный выбор с функцией автокомплита.
Схема базы неправильная. Отношения город-страна — многие к одному, и связь должна быть в City, а не Country.
При привязке городов к профилю, связь будет в профиле, один ко многим.
При привязке городов к профилю, связь будет в профиле, один ко многим.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой вариант MultipleInput + Autocomplete