P.S.
2. Этим решением, иерархия будет выглядеть как:
Россия / Москва / Ленинградский проспект
С возможностью быстро изменить путь, не вызывая модельные окна.
Основное требование — компактность
Очень компактно и сразу понятен и виден весь путь.
Делалось это для составления карточки документа в системе документооборота,
в которой около 30 полей.
Если не экономить место, пользователь вынужден часто пользоваться скроллом.
Можно работать с предложенным вами решением в отдельном модальном окне — это тоже вариант.
Кому-то подойдет он, — удачное решение для своих задач.
Я смотрел эти варианты.
Уважаемые хабропользователи, еще раз повторюсь — услышьте меня, пожалуйста.
Основное требование к элементу:
1. компактный
2. можно увидеть весь путь, по которому находится элемент.
3. Задача не в навигации по дереву и понимание его структуры, а именно выбор узла, сохранение выбранного
1. Деревья хорошо подходят для своих задач — когда на экране есть место.
Но если это не так, их приходится размещать в скроллинге и навигация в скроллинге, в котором скрыто 30 пунктов становится сложной.
2. Внутри иерархий есть одноименные узлы, например узел «Ленинградский проспект»
и недостаточно видеть узел, нужно видеть всю цепочку и без скроллинга и в компактном виде. нужно видеть ничего оператору не даст при отображении в таком виде:
-> родитель родителя (тоже скрыт за скроллом)
-> родитель (скрыт за скроллингом)
->… (30 строк)
-> Ленинградский проспект
3. Если сохранить выбранный узел в предложенном вами решении, то для того, чтоб показать выбранный, нужно развернуть иерархию снизу до самого верха. Это занимает много места. Хорошо, если оно есть. Но у меня другая ситуация.
Все это делает эти элементы неприменимыми для этой конкретной задачи.
Я не в коем случае, не настаиваю на универсальности этого отображения.
Я говорю, что для некоторых (соответствующих описанным требования) задач, этот вариант более подходит.
Это просто одна из альтернатив предложенных вами решений. Не лучше и не хуже — просто другая.
А возможность выбора — это всегда хорошо — кому-то пригодится (собственно, уже пригодилась паре человек, которых нет среди хабраюзеров).
Возможно, их много, а может быть, именно этого варианта нет среди них (все, которые я нашел, были именно разворачиванием деревьев).
Я не претендую на особую сложность и необычность серверной логики и не говорю, что это сложно написать (написал за 2 часа «с нуля»)
просто хочу предложить хабрасообществу и всем, кто набредет на статью, еще одну из альтернатив, которая может подойти кому-то для каких-то специфических задач больше.
Простите.
«Система за раз подгружает только один уровень»:
только при выборе очередного узла.
При инициализации загружается родительский узлы и все дети (этих узлов) на один уровень.
То есть, если инициализирующий узел вложен на 5 уровней, то будут собраны 5 ComboBox-ов — они же «select» — ы
но в все это в фоне.
Если инициализирующий элемент не является «листом» дерева, то подгружается еще список узлов, подчиненных этому, чтоб оператор мог продолжить спускаться по дереву от инициализирующего узла.
Динамика нужна, чтоб разгрузить систему и клиента (браузер)
узлов достаточно много (около сотни тысяч).
Система за раз подгружает только один уровень,
выполняя в базе запрос, используя индексы, поэтому небольшой кусочек таблицы возвращает очень быстро.
И очень важным оказалось требование к компактности интерфейса.
Поле такого типа является частью карточки документа,
составленной из различных полей.
К тому же, если кол-во «детей» в узле велико, то сложно читается полный путь к узлу для оператора
Например:
Узел 1 (выбран)
=> Узел 2
=> Узел 3
=> Узел 4
…
=> Узел N (выбран)
Иерархия содержит достаточно много узлов и уровней.
Кол-во узлов может достигать десятки и сотни тысяч.
Пример, который нашел тут
выводит это сразу на экран.
Как мне показалось, основное назначение плагина — это сортировка, изменение и запоминание положения
узлов достаточно небольшой иерархии, которая может быть выведена на экран.
Что, соответственно, не подходит.
Нужно выбрать какой-то конкретный узел и записать его в карточку документа.
В карточке присутствуют много полей разного типа, кроме иерархического.
Поэтому нужно максимально компактно
Такая логика приведена тут только для иллюстрации и специфична для используемой (тестовой) структуры данных, — чтобы пример не был привязан к СУБД.
Но, тем не менее, добавил дополнительный комментарий.
2. Этим решением, иерархия будет выглядеть как:
Россия / Москва / Ленинградский проспект
С возможностью быстро изменить путь, не вызывая модельные окна.
Основное требование — компактность
Очень компактно и сразу понятен и виден весь путь.
Делалось это для составления карточки документа в системе документооборота,
в которой около 30 полей.
Если не экономить место, пользователь вынужден часто пользоваться скроллом.
Можно работать с предложенным вами решением в отдельном модальном окне — это тоже вариант.
Кому-то подойдет он, — удачное решение для своих задач.
Уважаемые хабропользователи, еще раз повторюсь — услышьте меня, пожалуйста.
Основное требование к элементу:
1. компактный
2. можно увидеть весь путь, по которому находится элемент.
3. Задача не в навигации по дереву и понимание его структуры, а именно выбор узла, сохранение выбранного
1. Деревья хорошо подходят для своих задач — когда на экране есть место.
Но если это не так, их приходится размещать в скроллинге и навигация в скроллинге, в котором скрыто 30 пунктов становится сложной.
2. Внутри иерархий есть одноименные узлы, например узел «Ленинградский проспект»
и недостаточно видеть узел, нужно видеть всю цепочку и без скроллинга и в компактном виде. нужно видеть ничего оператору не даст при отображении в таком виде:
-> родитель родителя (тоже скрыт за скроллом)
-> родитель (скрыт за скроллингом)
->… (30 строк)
-> Ленинградский проспект
3. Если сохранить выбранный узел в предложенном вами решении, то для того, чтоб показать выбранный, нужно развернуть иерархию снизу до самого верха. Это занимает много места. Хорошо, если оно есть. Но у меня другая ситуация.
Все это делает эти элементы неприменимыми для этой конкретной задачи.
Я не в коем случае, не настаиваю на универсальности этого отображения.
Я говорю, что для некоторых (соответствующих описанным требования) задач, этот вариант более подходит.
Это просто одна из альтернатив предложенных вами решений. Не лучше и не хуже — просто другая.
А возможность выбора — это всегда хорошо — кому-то пригодится (собственно, уже пригодилась паре человек, которых нет среди хабраюзеров).
Возможно, их много, а может быть, именно этого варианта нет среди них (все, которые я нашел, были именно разворачиванием деревьев).
Я не претендую на особую сложность и необычность серверной логики и не говорю, что это сложно написать (написал за 2 часа «с нуля»)
просто хочу предложить хабрасообществу и всем, кто набредет на статью, еще одну из альтернатив, которая может подойти кому-то для каких-то специфических задач больше.
А кому-то, конечно, не подойдет. И это нормально
«Система за раз подгружает только один уровень»:
только при выборе очередного узла.
При инициализации загружается родительский узлы и все дети (этих узлов) на один уровень.
То есть, если инициализирующий узел вложен на 5 уровней, то будут собраны 5 ComboBox-ов — они же «select» — ы
но в все это в фоне.
Если инициализирующий элемент не является «листом» дерева, то подгружается еще список узлов, подчиненных этому, чтоб оператор мог продолжить спускаться по дереву от инициализирующего узла.
узлов достаточно много (около сотни тысяч).
Система за раз подгружает только один уровень,
выполняя в базе запрос, используя индексы, поэтому небольшой кусочек таблицы возвращает очень быстро.
И очень важным оказалось требование к компактности интерфейса.
Поле такого типа является частью карточки документа,
составленной из различных полей.
К тому же, если кол-во «детей» в узле велико, то сложно читается полный путь к узлу для оператора
Например:
Узел 1 (выбран)
=> Узел 2
=> Узел 3
=> Узел 4
…
=> Узел N (выбран)
Или:
Узел 1 / Узел 6
Кол-во узлов может достигать десятки и сотни тысяч.
Пример, который нашел тут
выводит это сразу на экран.
Как мне показалось, основное назначение плагина — это сортировка, изменение и запоминание положения
узлов достаточно небольшой иерархии, которая может быть выведена на экран.
Что, соответственно, не подходит.
Нужно выбрать какой-то конкретный узел и записать его в карточку документа.
В карточке присутствуют много полей разного типа, кроме иерархического.
Поэтому нужно максимально компактно
Не вычищенный мусор.
Такая логика приведена тут только для иллюстрации и специфична для используемой (тестовой) структуры данных, — чтобы пример не был привязан к СУБД.
Но, тем не менее, добавил дополнительный комментарий.