ru Бредкрамбы и свои урлы

[vosi]

Напишу по-русски, чтоб быстрей понять друг друга
Ситуация
дерево
/about/
*/about/team/
**/about/history/
*/products/

урл продуктов обрабатывает другая аппа, естесно
урл продуктов может строится по разному (/products/category/_/, /products/type/_/, /products/item/***/), но начинается с /products/
задача, выводить бредкрамбы наполовину через сайттри
т.е. чтоб все то, с чем может разобраться сайттри выводилось сайттри, остальное - сам буду докидывать в темлейт
(link Products > link Category > Type)
в данный момент, если я на странице /products/something/ бредкрамба не выводится вообще, естественно
так как я не до конца вник в логику построения всех деревьев в аппе, сделал такой грязный хак https://github.com/vosi/django-sitetree/commit/6a6f7674010d6e535c8dfda05872d1f9c836d60c

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

кстати, недоделка по менюхам, с целым плагин менегером (https://github.com/dhan88/django-treemenus)

[idlesign]

Давай на ты, Володь.
А зачем размазывать навигацию по разным местам, ведь так её сложнее будет поддерживать?
Создание веток для category, type, item и something с именоваными урлами не решит задачу?

[vosi]

ок, как ты предлагаешь выводить бредкрамбу?
дом - продукция - пишущие пренадлежности - ручки - ручка продир м15 красная
на данный момент "дом - продукция" - както решено
остальное, дописывать в темплейт бредкрамбы, передавая нужные вещи из вьюхи апликухи магазина втемплейт бредкрамбы (темплейттагом например)
ну а можно было б заюзать некий метод от сайттри и пушнуть "пишущие пренадлежности - ручки - ручка продир м15 красная" в меню "продукция", для использования в бредкрамбе

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

[idlesign]

Я правильно понял, что весь фокус в том, что у тебя ненормированная длина цепочки?

[vosi]

это тоже

[alekam]

Как я понял идея в том, чтобы после определенного уровня дерево достраивалось само, без ручного редактирования таблиц sitetree.

Бедкрамб можно поделить на составные (в порядке увеличения детализации):

• крошки до приложения - генерируется с помощью sitetree
• вьюхи внутри приложения - генерируется с помощью sitetree (как есть сейчас) либо самой вьюхой (к крошкам приложения добавляем название вьюхи)
• состояния вьюхи (возможно, но не обязательно) - вьюхой (навигация по вложенным категориям)

[idlesign]

Бум думать.

[idlesign]

Володь, посмотри пожалуйста, пример дерева, приведенный ниже, насколько он решает твою задачу?
Формат: название_из_твоего_примера = именованный_урл_с_параметрами -- название_элемента_дерева.

дом - /
  |- продукция = products_idx -- Продукция
      |- пишущие пренадлежности = products_category category.id -- category.title
          |- ручки = products_type category.id type.id -- type.title
             |- ручка продир м15 красная = products_item category.id type.id item.id -- item.title

[vosi]

где-то как-то так )

[idlesign]

Дэк, если решает, то зачем велосипеды изобретать?

[alekam]

1 раз это вбить - не проблема. В следующем проекте на почти аналогичном движке тоже придется поступить так же. И в следующем... Через фикстуры загрузить не получится - не известна нода, к которой нужно присоединить корневой урл приложения.
Как вариант можно в init.py приложения разместить структуру, содержащую эти данные и подгрузить ее с помощью команды.

[idlesign]

У оказывается как плохо-то, когда что ни проект, то магазин %)
Вообще лесенка из четырех элементов набивается за две-три минуты.

Алексей, приведи пример стуктуры для init.py, разберем.

[alekam]

Ничего путного что-то в голову не идет.

Допустим есть команда 'install_sitetree_app_node <app_name> <root_node_id>'. При запуске она пытается импортировать из init.py приложения функцию install_sitetree_node и вызывать ее, чтобы создать объекты TreeItem.

Функция возвращает список, содержащий узлы дерева sitetree в виде словаря. Ключи словаря - поля модели TreeItem. Здесь есть проблема с разрешением идентификаторов родителей дочерних узлов внутри модуля или с ссылками на другие модули. Возможный вариант решения - добавить к модели TreeItem natural key и использовать его.

from django.utils.translations import ugettext as _

def install_sitetree_node():
   return [
     {
       'parent': -1, # root
       'title': _('qwerty'),
       'url': ...,
       'access_loggedin': True,
       ...
     }, ...
   ]

Как-то так. Другой вариант - сразу в этой функции создавать объекты TreeItem (так наверно даже проще).

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

[idlesign]

Спасибо, Алексей.

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

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

На досуге продолжу думать %)
Если появятся идеи, накидывайте.

[alekam]

Блин, из-за разметки часть команды потерялась. Отличия от фикстур в том, что можно передать корневой элемент, к которому нужно присоединить все дерево.

install_sitetree_app_node <app_name> [root_node_id]

В текущем виде (FK связи по id) фикстуры использовать сложно, но в общем случае для объектов TreeItem natural key построить не получится. Таким образом со стандартными фикстурами универсального решения не получится, либо придется писать хитрую команду загрузки, которая пересчитывает идентификаторы элементов при загрузке, заменяя их на актуальные.

[idlesign]

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

[alekam]

Тоже верно. Но тогда как разрешить связи между узлами внутри приложения? Когда генерируешь фикстуру будут сохранены одни идентификаторы, а когда ее загружаешь в другой проект эти идентификаторы могут быть уже заняты и тогда произойдет подмена узлов.

[idlesign]

Стало быть понадобится команда, которая будет генерить фикстуры с опциональной возможностью не сохранять id для корневых [либо принимаемых за корневые] элементов. Такие элементы при импорте будут помещены в корень нового дерева, далее их постановка на нужное место должна будет производиться в админке.

[vosi]

Очень нужна команда
Новых идей, кроме озвученных выше, не приходит

есть только иллюстрация
http://ubuntuone.com/1ctx1bCydP3Ytf4KND5xAg
и таких еще 3 разворота

долго и нудно наполнял дерево (((

[idlesign]

Иллюстрация внушает %) Решим, Володь, но уже врядли в 0.6.

[alekam]

Блин, работа меня захватила (
В текущих проектах нет необходимости в данном приложении, так что я тоже даже концепт реализую не скоро.

В скрине Володи структура большинства веток похожая: Категория / Подкатегория / Статья. Как-то наверно это можно все таки упростить. Или все разделы забиты ради красивого дерева сайта или сортировки пунктов в менюшке?

[vosi]

вот живой сайт http://imxo.mx/uk/home/

[idlesign]

Здесь две задачи в одном репорте. Первая соответствует загловку, и, похоже, может быть решена с помощью register_items_hook(), а вторая — это экспорт. Вот для второй я, пожалуй, заведу новый репорт.

[idlesign]

По команде экспорта см. #36.