Справочники главный и подчиненный, хлебные крошки и как это все сделать?

@Kifsif · Регистрация: 12.06.2011

Студворк — интернет-сервис помощи студентам

Django 1.9.7

Делаю основной и подчиненный справочник:
Основной - Место и к нему подчиненный - Историческое название места.

Думал сделать это на CreateView и DetailView.

А еще использую на сайте хлебные крошки.

Так вот - был я тут:

places/(slug)/create_name

А после создания наименования хотел бы оказаться тут:

places/(slug)/place_names/(slug)

Но по умолчанию фреймворк хочет перевести меня сюда:

place_names/(slug)

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

Главная / Названия мест / Москва

Совершен прыжок в совершенно произвольное место сайта. При этом пользователь ведь создал наименование из страницы "Место". Т.е. он может захотеть вернуться и ввести еще одно историческое наименование места.

Во-вторых, такого перечня как "Названия мест" вообще я бы пользователю показывать не хотел - там будет солянка полная - Сталинград с Петербургом перемешаются и будут сидеть в алфавитном порядке. Это не нужно, нет такого перечня как элементы подчиненного справочника без привязки к главному. Туда вообще нельзя пользователя заводить: ни хлебными крошками, никак по-другому.

А вот в главном справочнике "Место" исторические названия будут выведены списочком с сортировкой по дате присвоения названия.

Вот сделать так, как я хотел - places/(slug)/place_names/(slug) - у меня с наскоку не получилось. Это надо как-то success_url придумывать. Я не уверен, что я его смогу придумать. Может быть, мне придется отказаться от CreateView. Это, я думаю, возможно, но гораздо более трудоемкое дело.

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

Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class Place(models.Model):
    """
    Uniquely idenfity the place. Slug = zip code.
    """
    slug = models.SlugField(max_length=9, default="", 
                                   blank=False, null=False, unique=True)
 
class PlaceName(models.Model):
    """
    Historical names of Place.
    """
    one = ForeignKey(Place, on_delete=models.CASCADE)
    name = models.CharField("max_length=200, blank=False, 
                                   null=False, default="", db_index=True)
    since = models.PositiveIntegerField(blank=True, null=True, 
                                        validators=[MaxValueValidator(9999)])
 
 
class PlaceNameCreate(CreateView):
    model = PlaceName
    fields = ['one', 'name', 'since', ]

@Zuzik · 02.07.2016, 23:44

Сообщение от Kifsif

Делаю основной и подчиненный справочник:

что такое справочник в вашем понимании?

Сообщение от Kifsif

places/(slug)/create_name
А после создания наименования хотел бы оказаться тут:
places/(slug)/place_names/(slug)
Но по умолчанию фреймворк хочет перевести меня сюда:

не он хочет, а вы ему так сказали.

Не по теме:

П.С, и вообще - то, что вы хотите сделать понять тяжеловато. Перечни, справочники, вы про что вообще пишете??????????

@Kifsif · 03.07.2016, 00:08 **[ТС]**

Сообщение от Zuzik

что такое справочник в вашем понимании?

Справочник - это объект, содержащий список данных. При этом у главного и подчиненного справочника отношения один ко многим. Главный справочник будет содержать индексы или коды территорий. Подчиненный - расшифровку исторических названий к ним.

Сообщение от Zuzik

П.С, и вообще - то, что вы хотите сделать понять тяжеловато. Перечни, справочники, вы про что вообще пишете??????????

Собственно говоря, я затрудняюсь написать для PlaceNameCreate такой success_url, чтобы после создания объекта PlaceNames был переход на url вида places/(slug)/place_names/(slug).

Если это не делается через CreateView, если бы подсказали - так ты не сделаешь, делай свой класс наследником от View.

@Zuzik · 03.07.2016, 10:41

Сообщение от Kifsif

Справочник

модель, или таблица базы данных. Не справочник.

По поводу вашей задачи - т.е. вы хотите сделать урл вида places/санкт-петербург/place_names/ленинград, и хранить в базе данных данные о обоих городах отдельно, и делать 2 разные страницы на отображение данных? А зачем так усложнять жизнь себе и пользователю?

тут проще по странице на каждый город и все, а в начале страницы указывать старые названия, и года, когда он так назывался.
т.е. places/ленинград
а в содерижмом страницы
данное название - с ... по...
текущее название - с.... по ...

Добавлено через 1 минуту
либо вообще по одной странице на каждый город вне зависимости от старых названий, просто предусмотреть поиск по ним, и указывать пользователю - вы искали ленинград, клацнули ссылку и попали на санкт петербург, потому что это старое название.

@Kifsif · 03.07.2016, 10:54 **[ТС]**

Сообщение от Zuzik

places/санкт-петербург/place_names/ленинград

Нет.

places/198000/place_names/санкт-петербург
places/198000/place_names/ленинград
places/198000/place_names/петроград

Сообщение от Zuzik

делать 2 разные страницы на отображение данных? А зачем так усложнять жизнь себе и пользователю?

Да, планирую сделать так. Подоплека в нормализации базы. При этом все это будет, действительно, на разных странциах. Я бы сделал это на одной, но не умею.

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

Но я так пока сделать не в состоянии. Да ладно, откроют в новом окне - ничего страшного.

Сообщение от Zuzik

тут проще по странице на каждый город и все, а в начале страницы указывать старые названия, и года, когда он так назывался.
т.е. places/ленинград

Так и будет, но для юзера. На странице places/198000 помещен тег, который вытащит данные из модели place_names.
А делать-то все равно надо две таблицы: Place и PlaceName.

Добавлено через 6 минут

Сообщение от Kifsif

Так и будет, но для юзера.

Пардон, для просмотра. Для создания и редактирования я так сделать не в состоянии.

@Zuzik · 03.07.2016, 11:01

Сообщение от Kifsif

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

не надо так думать, попробуйте, научитесь. Главное сделайте нормально. Тем более это довольно просто будет.

Сообщение от Kifsif

Подоплека в нормализации базы.

будьте так любезны, почитайте что такое нормализация базы данных, и хорошо это обдумайте. Ваши действия имеют с ней мало общего

@Kifsif · 03.07.2016, 11:09 **[ТС]**

Сообщение от Zuzik

будьте так любезны, почитайте что такое нормализация базы данных, и хорошо это обдумайте. Ваши действия имеют с ней мало общего

Вот зачем так отвечать? Иди, дескать, учись и, там, вообще, поройся в книжках.

Есть конкретная задача. С накоплением осознанной практики решения таких задач придет и опыт.

А пока лучше бы подсказали, что конкретно сделано неправильно. Какие должны быть модели и как это все помещается на одну страницу.

Если взять эту задачу немного более абстрактно, то есть местность. Город, регион и т.п. Эту местность надо идентифицировать и хранить перечень ее исторических названий. Ну, я и взял для населенных пунктов почтовый индекс, для регионов - код региона. В модели Place этот код будет храниться в поле slug. Маленькая модель, но база вполне нормализована.

@Zuzik · 03.07.2016, 11:47

2 таблицы
1ая
название города
с какого года по какой носил такое название
поле внешний ключ на вторую таблицу
2ая
подробная информация о городе, не зависимости от названия

делаем 1 урл - places/{имя_города}

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

в шаблоне - выводишь информацию сначала о всех названиях, потом собственно о городе.

это первый вариант.
само собой - сугубо примерно, возможны вариации

Добавлено через 7 минут
второй вариант
1
название города
года в которые носил данное название
информация по данному временному периоду
внешний ключ ко второй таблице
2
идентификатор города (уникальный)

урл по прежнему один и тот же

во вьюшке
по названию города узнаем идентификатор из второй таблицы.
берем все города по индентификатору из второй таблицы

в шаблоне
выводим список всех названий как содержание.
потом информацию о каждом названии города.

Этот вариант даже более красивым кажется.

@Kifsif · 03.07.2016, 12:20 **[ТС]**

Тогда, получается, надо отказаться от готовых generic views, сделать свою форму, которая при отработке метода post просто напишет строчки в две таблицы. Вроде бы, что-то проясняется.

А как это делается?

Для первой таблицы: сначала рендеришь форму с одной строчкой. А потом надо как-то на страницу срендерить формочку для второй строчки. Это надо AJAX использовать?

@Zuzik · 03.07.2016, 15:29

Сообщение от Kifsif

Для первой таблицы: сначала рендеришь форму с одной строчкой. А потом надо как-то на страницу срендерить формочку для второй строчки. Это надо AJAX использовать?

не совсем понял, что вы имеете ввиду. Если при добавлении записи-форму в которой вводишь данные все о городе, + еще одно поле с названием "Другое название" в котором выводить список вида 1-ая строка Ленинград,Санкт-петербург, 2-ая строка Волгоград, Сталинград(прошу не пинать, если не прав), с возможностью выбрать одну строку. Исходя из этой строки брать айдишник и делать соотвествующую запись во второй таблице.

Либо для этих же дел, настроить админку в джанге,так это делается довольно просто

@Kifsif · 03.07.2016, 16:18 **[ТС]**

Так, давайте с почти чистого листа. А именно сохраним модели из первого поста. Остальное все отбросим.

Нужно:

1) Логичная навигация по сайту. Т.е. чтобы пользователь, стерев часть урла, оказался в предсказуемом месте.
2) Админку использовать нельзя - строим исключительно пользовательский интерфейс.

Как я видел это до нашей беседы.
1. Урлы:
1) places - список кодов территорий и населенных пунктов. Код - это уникальная штука. Либо это почтовый индекс, либо это код региона (гаишный или ОКАТО, юзеры сами разберутся). Код пишем сразу в поле slug. И в конце кнопка - "Добавить". О городе я информацию хранить не планировал. Но мне нужен уникальный код территории.
2) places/(slug) - информация о городе с помощью DetailView. Здесь кнопки: 1) "Редактировать", 2) "Добавить название".
3) places/(slug)/place_names - список названий данной территории. Кнопка "Добавить название".
4) places/(main_slug)/place_names/create - добавляет еще одно название для данной территории.
5) places/(main_slug)/place_names/(sub_slug) - выводит подробности об этом названии с помощью DetailView. Здесь кнопка "Редактировать".
6) places/(main_slug)/place_names/(sub_slug)/edit - редактируем.

Вот эта навигация логична.

Фреймворк мне сейчас из коробки предлагает прыгнуть из places/(main_slug)/place_names/create на place_names/(slug). Это нарушит логику навигации по сайту, мне кажется. Но это как бы в уме. Теоретически это нам подходит - ну, список названий. Это даже неплохо - не индексы же показывать юзеру (как в случае с places), а это вполне осмысленный список.

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

Теперь что у нас получается. Если попытаться отказаться от place_names в урлах, и обратиться, как вы советуете к варианту places/{имя_города}.

Это возможно, но нужно будет для сохранения логики навигации переделать все урлы вот так:
1. places - список территорий. Здесь уже с названиями.
2. places/(slug) - детализация. Из Place достаем код, он там в поле slug. Из PlaceName достаем подробности об исторических наименованиях и годах.
3. places/create - а вот тут уже облом полный для меня. Я так сделать не умею. Это надо на страницу поместить форму для модели Place, ниже форму для модели PlaceName и вывести поля name и since. И еще надо здесь расположить кнопочку в виде плюсика. Которая добавит еще один ряд для полей name и since. И так до бесконечности, пока юзере не остановится.
При выполнении метода POST надо обработать сначала первую форму и создать объект Place. Затем обрабатывать все строки с историческими названиями, для каждой создавая отдельный объект модели PlaceName.

Вот я так вас понял. Как это сделать, я не знаю. У каждой формы csrf_token. Не делал, не умею. Хотел Django поучить, а у тут - смотрю, AJAX что-ли нужен. Посмотрел пример https://docs.djangoproject.com... ax-example. Ничего не понял. Может быть, был бы там пример еще и с фронтендом, он бы и ничего. А так - отложил джангу, надо аякс учить, а как его учить, знаний по JavaScript не хватает. Вот теперь все брошено, давай теперь то подтягивать. Ну, вот что тут делать.

@Zuzik · 03.07.2016, 17:52

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

@Kifsif · 05.07.2016, 12:24 **[ТС]**

Что-то я сделал. Такой прототипчик. Но я, по сути, лишился всех механизмов фреймворка.

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

Потом разбирал списки и создавал объекты моделей.

В результате сделал какой-то ужас, еще валидацию не прикрутил. И еще не пробовал делать редактирование всего этого ужаса.

Получилось очень трудоемко, подвержено ошибкам, да еще и не доделано до конца. И это только для одной пары главной и подчиненной модели. А их будет много.

В общем, не вариант. С таким подходом меня вообще могут на смех поднять, если кто увидит этот код.

Т.е., мне кажется, что:
1. Это неверное решение с точки зрения архитектуры приложения.
2. Должно быть какой-то уже проторенный путь. Ну, не может быть, чтобы такой ужас постоянно все писали вручную. Либо готовое приложение есть, либо формочки AJAX'ом принято добавлять.

В общем, надо переделывать. AJAX я поучить готов. Все равно его пробовать надо.

Что скажете?

Новые блоги и статьи Все статьи Все блоги /
YAFU@home — распределённые вычисления для математики. На CPU Programma_Boinc 20.01.2026 YAFU@home — распределённые вычисления для математики. На CPU YAFU@home — это BOINC-проект, который занимается факторизацией больших чисел и исследованием aliquot-последовательностей. Звучит. . .	http://iceja.net/ математические сервисы iceja 20.01.2026 Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .	http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь постоянного тока с R, L, C, k(ключ), U, E, J. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа, решает её и находит: токи, напряжения и их 1 и 2 производные при t = 0;. . .
Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .

@Zuzik 298 / 256 / 57 Регистрация: 11.06.2012 Сообщений: 1,557
	03.07.2016, 11:47
	2 таблицы 1ая название города с какого года по какой носил такое название поле внешний ключ на вторую таблицу 2ая подробная информация о городе, не зависимости от названия делаем 1 урл - places/{имя_города} во вьюшке достаешь информацию из второй таблицы по имени города из урла, и все названия городов которые ссылаются на данные из первой таблицы и передаешь эту информацию в шаблон. в шаблоне - выводишь информацию сначала о всех названиях, потом собственно о городе. это первый вариант. само собой - сугубо примерно, возможны вариации Добавлено через 7 минут второй вариант 1 название города года в которые носил данное название информация по данному временному периоду внешний ключ ко второй таблице 2 идентификатор города (уникальный) урл по прежнему один и тот же во вьюшке по названию города узнаем идентификатор из второй таблицы. берем все города по индентификатору из второй таблицы в шаблоне выводим список всех названий как содержание. потом информацию о каждом названии города. Этот вариант даже более красивым кажется. 0

@Kifsif 145 / 113 / 31 Регистрация: 12.06.2011 Сообщений: 1,246
	03.07.2016, 12:20 [ТС]
	Тогда, получается, надо отказаться от готовых generic views, сделать свою форму, которая при отработке метода post просто напишет строчки в две таблицы. Вроде бы, что-то проясняется. А как это делается? Для первой таблицы: сначала рендеришь форму с одной строчкой. А потом надо как-то на страницу срендерить формочку для второй строчки. Это надо AJAX использовать? 0

@Kifsif 145 / 113 / 31 Регистрация: 12.06.2011 Сообщений: 1,246
	03.07.2016, 16:18 [ТС]
	Так, давайте с почти чистого листа. А именно сохраним модели из первого поста. Остальное все отбросим. Нужно: 1) Логичная навигация по сайту. Т.е. чтобы пользователь, стерев часть урла, оказался в предсказуемом месте. 2) Админку использовать нельзя - строим исключительно пользовательский интерфейс. Как я видел это до нашей беседы. 1. Урлы: 1) places - список кодов территорий и населенных пунктов. Код - это уникальная штука. Либо это почтовый индекс, либо это код региона (гаишный или ОКАТО, юзеры сами разберутся). Код пишем сразу в поле slug. И в конце кнопка - "Добавить". О городе я информацию хранить не планировал. Но мне нужен уникальный код территории. 2) places/(slug) - информация о городе с помощью DetailView. Здесь кнопки: 1) "Редактировать", 2) "Добавить название". 3) places/(slug)/place_names - список названий данной территории. Кнопка "Добавить название". 4) places/(main_slug)/place_names/create - добавляет еще одно название для данной территории. 5) places/(main_slug)/place_names/(sub_slug) - выводит подробности об этом названии с помощью DetailView. Здесь кнопка "Редактировать". 6) places/(main_slug)/place_names/(sub_slug)/edit - редактируем. Вот эта навигация логична. Фреймворк мне сейчас из коробки предлагает прыгнуть из places/(main_slug)/place_names/create на place_names/(slug). Это нарушит логику навигации по сайту, мне кажется. Но это как бы в уме. Теоретически это нам подходит - ну, список названий. Это даже неплохо - не индексы же показывать юзеру (как в случае с places), а это вполне осмысленный список. Вот чтобы все вышесказанное сделать, можно было открывать формы для добавления чего-то в новых вкладках. Такая была задумка. Теперь что у нас получается. Если попытаться отказаться от place_names в урлах, и обратиться, как вы советуете к варианту places/{имя_города}. Это возможно, но нужно будет для сохранения логики навигации переделать все урлы вот так: 1. places - список территорий. Здесь уже с названиями. 2. places/(slug) - детализация. Из Place достаем код, он там в поле slug. Из PlaceName достаем подробности об исторических наименованиях и годах. 3. places/create - а вот тут уже облом полный для меня. Я так сделать не умею. Это надо на страницу поместить форму для модели Place, ниже форму для модели PlaceName и вывести поля name и since. И еще надо здесь расположить кнопочку в виде плюсика. Которая добавит еще один ряд для полей name и since. И так до бесконечности, пока юзере не остановится. При выполнении метода POST надо обработать сначала первую форму и создать объект Place. Затем обрабатывать все строки с историческими названиями, для каждой создавая отдельный объект модели PlaceName. Вот я так вас понял. Как это сделать, я не знаю. У каждой формы csrf_token. Не делал, не умею. Хотел Django поучить, а у тут - смотрю, AJAX что-ли нужен. Посмотрел пример https://docs.djangoproject.com... ax-example. Ничего не понял. Может быть, был бы там пример еще и с фронтендом, он бы и ничего. А так - отложил джангу, надо аякс учить, а как его учить, знаний по JavaScript не хватает. Вот теперь все брошено, давай теперь то подтягивать. Ну, вот что тут делать. 0

@Zuzik 298 / 256 / 57 Регистрация: 11.06.2012 Сообщений: 1,557
	03.07.2016, 17:52
	Можно и без аякса, пробуйте. Начинайте реализовывать, будут вопросы по реализации - спрашивайте, помогут. 0

@Kifsif 145 / 113 / 31 Регистрация: 12.06.2011 Сообщений: 1,246
	05.07.2016, 12:24 [ТС]
	Что-то я сделал. Такой прототипчик. Но я, по сути, лишился всех механизмов фреймворка. Т.е. я на страницу надобавлял джаваскриптом полей для ввода названия места и года присвоения названия. Потом передал это все на сервер. Там немного чистил, запоминал расположение введенной пользователем информации, чтобы, если юзер ошибся, вернуть ему форму в том виде, как он ее заполнил. Потом разбирал списки и создавал объекты моделей. В результате сделал какой-то ужас, еще валидацию не прикрутил. И еще не пробовал делать редактирование всего этого ужаса. Получилось очень трудоемко, подвержено ошибкам, да еще и не доделано до конца. И это только для одной пары главной и подчиненной модели. А их будет много. В общем, не вариант. С таким подходом меня вообще могут на смех поднять, если кто увидит этот код. Т.е., мне кажется, что: 1. Это неверное решение с точки зрения архитектуры приложения. 2. Должно быть какой-то уже проторенный путь. Ну, не может быть, чтобы такой ужас постоянно все писали вручную. Либо готовое приложение есть, либо формочки AJAX'ом принято добавлять. В общем, надо переделывать. AJAX я поучить готов. Все равно его пробовать надо. Что скажете? 0