Цитата:
Сообщение от
Владимир Максимов
Narayana
Какая-то каша у Вас получается.
TreeView - это инструмент визуализации определенной структуры. Именно в этом качестве он и используется.
Однако есть разница, использовать TreeView для фильтрации данных в повседневной работе (когда TreeView - это первый объект поиска) и использовать TreeView как некий отчет, "фотографию текущего момента" (когда TreeView - это последний объект)
Так вот, как "фотография текущего момента" TreeView вполне себе уместен и широко используется. Например, в спецификациях, чтобы отобразить набор компонентов одной конкретной спецификации.
Однако как инструмент повседневной работы для поиска и фильтрации данных - крайне не удобен и желательно всячески избегать именно такого его применения.
В частности, группы номенклатуры. Предположим, Вы "подвесили" это дерево в форме номенклатуры (привет Retail). Как Вы себе представляете поиск номенклатуры, если Вам заранее не известно к какой именно группе она принадлежит? А как Вы отобразите результат поиска? Практика показывает, что это самое дерево так и висит как "чемодан без ручки". И тащить тяжело и выбросить жалко
Кстати, Вы статью, ссылку на которую дал
mazzy, читали? На всякий случай приведу ее еще раз
http://axapta.mazzy.ru/lib/tree/
Кроме того, там в правом верхнем углу есть еще ссылка на обсуждение этой статьи
http://forum.mazzy.ru/index.php?showtopic=1275&st=0
PS: Если Вы не поняли, то у Columbus есть решение для розничной торговли (retail), где как раз группы номенклатур в виде TreeView подвешены сверху над списоком номенклатуры. Так вот, кроме недоумения, это TreeView ничего не вызывает. Зачем? Ну зачем они это сделали? Не используется ведь... Столько места бестолку занимает...
Все читал, все смотрел и даже немного думал об этом обо всем...
Мне кажется, вы не признаете очевидного. А именно того, что правильно составленная иерархия номенклатур, тому человеку, который ее составил, позволяет сравнительно легко ориентироваться в списке номенклатур.
Думаю, что вы при этом забываете про потребность не только найти номенклатуру, про которую знаете, что она есть, но и просто посмотреть, что есть в разных уровнях иерархии.
Спорить о вкусах здесь сложно.
Сразу вспоминается рассказ про владельца магазина, который весь товар с полок и из ящиков вываливал на пол, а когда приходили покупатели, довольно быстро находил то, что нужно. Правда, не заладились у него отношения с окружающим миром.
Тем не менее, в материальном мире более-менее соблюдается принцип декомпозиции, а все противоположное называется бардаком.
Ну, хорошо, вам сложно полистать узлы TreeView, чтобы понять, по какому принципу сортируется товар, а каким образом вы, не будучи программистом, будете исследовать вопрос о том, по каким полям в связанных таблицах вы можете фильтровать записи в основной таблице??
Речь ведь идет не только о полях, которые есть в основной таблице номенклатур.
Почему-то вопрос о связанных таблицах с дополнительными атрибутами все время стыдливо опускается, но ведь это и есть самое сложное место.
При этом при построении фильтра над целой гроздью таблиц, в поиск можно включить значения полей только непосредственно связанных между собой таблиц, а вот через одну уже нельзя. Ну и где в этом месте ваша хваленая фильтрация?
В общем не так все просто, чтобы надувать щеки только в сторону одного варианта.
TreeView был и будет занимать одно из самых важных и сложных мест интуитивного пользовательского интерфейса, хотите вы этого или нет.
Просто потому, что это пользователю понятно, а форма построения сложного фильтра, которая просто воспроизводит SQL запрос, - не понятна большинству.