Создание иерархии в виде дерева для фронта приложения на Джанго.

django, mptt

Рекомендуємо хостинг TIMEWEB

Stabiles Hosting des sozialen Netzwerks EVILEG. Wir empfehlen VDS-Hosting für Django-Projekte.

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

все просто, представьте себе следуешее:

открываем браузер, вписываем адрес и открывается страница:

и мы начинаем с лева добавлять элементы в дереве а с права для каждого элемента какой то контент, вот еше несколько скринов:

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

как я понимаю, если говорить с точки зрения хранениния данных в базе ТО для каждого элемента нам надо определить поле родитель, и на пример если у елемета нету родителя (т.е. это корневой элемент) у нег значение поля родитель нул, и дальже идет какой то алгоритм - по сути, понятно что речь идет о дереве и о алгоритме обхода дерева.

ну конечно если к данному функционалу добавить еше возможность drag-and-drop, то есть находу менять порядок элементов в данном дереве то вооше получится бомба пакет для опенсурс-а, и тут для drag-and-drop нужен ajax, это 10000%

я попытался разобраться в mptt, а вернее сказать как он сохраняет данные и по какому алгоритму. вот к чему я пришел:

1. mptt создает таблицу для модель ее типа:

поле parent_id показывает родителя, если null то корневой, если не null то id родителя
поле mptt_level показывает глубину по горизонтале НО не показывает кто именно родитель
поле tree_id , вот ту интереснее, как я понял если mptt_level равно 0 то tree_id это порядок по вертикали а если mptt_level не равно 0 показывает на родителя НО опять есть нюансы

главная инфа в mptt дереве находится в полях lft, rght, tree_id

пока вот это.

в принципе думаю что понятно что я хочу замутить.

ну я бы не стал ломать голову и сделал бы какое-нибудь json api. а в него с фронта все передавал бы то, что там делается.

мне кажется, пытаться это сделать средствами статического рендеринга django - непоравдано по сложности

то есть, под json api вы имеите в виду что:

на фронте, используя js или какой то js библиотекой (на пример www.jstree.com) которое уже знает про ajax строить дерево а уже гатовое дерево переводить в json и передавать бэку ?

тогда мне не понятно как к каждому элементу дерева присвоить какой то контент?

не совсем.
делается несколько ендпоинтов api, оди про саму структуру, второй про контент.

на фронте делается следующее: при создании нового узла дерева - post запрос в апи с указанием id родителя и названием, вернуть id созданного узла. если родителя нет - значит это корневой узел. при создании контента к узлу - post запрос в апи с указанием id узла и собственно содержимого, вернуть id обьекта созданного контента. при обновлении - put запрос, при удалении - delete запрос.при этом контент может быть сложнее, чем просто текст

у меня тут идет привязка: элемент дерева <-> контент = один к одному

вы советуете 2 ендпоинта, по одному на каждую сторону, которые как бы будут автономны??

или же можно сделать один ендпоинт и в этом случаеа фронт будет строить большой жсон для отправки бэку в котором будут оби стороны ??

просто, из за неопытности в данной теме, мне немного не понайтно как будут потом синхронизироватся связь между: элемент дерева <-> контент

1 эндпоинт - элементы дерева, второй - контент. не надо мешать все в кучу.

добавился элемент дерева - запрос в первый эндпоинт, вернулся id созданного элемента, и когда создается контент, отарвляется запрос на второй эндпоинт с указанием - для элемента с таким-то id был создан такой-то контент.

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

а так все очень просто - каждое изменение фиксируется и сама обработка запроса неприлично простая