Использование TreeView в Ax2009

[Владимир Максимов]

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 ничего не вызывает. Зачем? Ну зачем они это сделали? Не используется ведь... Столько места бестолку занимает...

[Narayana]

Цитата:

Сообщение от Владимир Максимов

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 запрос, - не понятна большинству.

[Владимир Максимов]

Цитата:

Сообщение от Narayana

Все читал, все смотрел и даже немного думал об этом обо всем...

Похоже, главное слово в этом предложении "немного" Подумает еще, пожалуйста

Цитата:

Сообщение от Narayana

Мне кажется, вы не признаете очевидного. А именно того, что правильно составленная иерархия номенклатур, тому человеку, который ее составил, позволяет сравнительно легко ориентироваться в списке номенклатур.

Ключевое фраза в этом предложении "тому человеку, который ее составил". Это один из аргументов "против" в статье mazzy. И в статье он объясняет "почему". Перечитайте этот момент, пожалуйста.

Цитата:

Сообщение от Narayana

Думаю, что вы при этом забываете про потребность не только найти номенклатуру, про которую знаете, что она есть, но и просто посмотреть, что есть в разных уровнях иерархии.

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

Цитата:

Сообщение от Narayana

Спорить о вкусах здесь сложно.

Дело вовсе не во вкусах, а в практических проблемах, возникающих при использовании дерева. Задумайтесь о том, какие операции чаще всего выполняет пользователь со справочником. А потом прикиньте, как эти самые часто выполняемые операции изменятся (упростятся или усложняться) при обязательном (!) использовании дерева.

Цитата:

Сообщение от Narayana

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

А зачем мне это знать, если я не программист? В каких местах (формах) пользовательского интерфейса возникает подобная необходимость? И какое отношение к этому вопросу имеет TreeView?

Цитата:

Сообщение от Narayana

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

И каким образом в этой задаче может помочь TreeView?

Цитата:

Сообщение от Narayana

В общем не так все просто, чтобы надувать щеки только в сторону одного варианта.

Угу. Странно только, что Вы не применяете это правило к себе. Вы ведь не пытаетесь сравнить. Для Вас существует только один вариант

Цитата:

Сообщение от Narayana

TreeView был и будет занимать одно из самых важных и сложных мест интуитивного пользовательского интерфейса, хотите вы этого или нет.

Вы забыли уточнить, для каких именно задач. Никто ведь не отрицает удобство использования TreeView в определенных областях. Но пытаться "воткнуть" TreeView везде и всегда крайне порочная практика. К сожалению, многим требуются "шашечки", а не "ехать"

Цитата:

Сообщение от Narayana

Просто потому, что это пользователю понятно, а форма построения сложного фильтра, которая просто воспроизводит SQL запрос, - не понятна большинству.

Интересный вывод. Вы уверены, что читали статью mazzy? Перечитайте ее еще раз, пожалуйста. В данном случае о том, как именно (по каким критериям) фильтрует записи TreeView и что делать, если Вам надо задать другой критерий фильтрации. Не тот по которому построено TreeView.