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

@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 я поучить готов. Все равно его пробовать надо.

Что скажете?

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Обработчик клика мыши в браузере ПК и касания экрана в браузере на мобильном устройстве 8Observer8 02.02.2026 Содержание блога Для начала пошагово создадим рабочий пример для подготовки к экспериментам в браузере ПК и в браузере мобильного устройства. Потом напишем обработчик клика мыши и обработчик. . .	Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .	SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .
SDL3 для Web (WebAssembly): Установка Emscripten SDK (emsdk) и CMake для сборки C и C++ приложений в Wasm 8Observer8 30.01.2026 Содержание блога Для того чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. . . .	SDL3 для Android: Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .	SDL3 для Android: Загрузка PNG с альфа-каналом с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 28.01.2026 Содержание блога SDL3 имеет собственные средства для загрузки и отображения PNG-файлов с альфа-каналом и базовой работы с ними. В этой инструкции используется функция SDL_LoadPNG(), которая. . .

@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