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

[Narayana]

Цитата:

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

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

Ну, хорошо, допустим у вас есть поле в строке номенклатуры, по значению которого вы можете сделать поиск и отобрать записи, у которых в данном поле значение фильтра.
Например, деталь ХХХ входит в агрегат УУУ.
Мы организовываем поиск по значению УУУ в поле "агрегат" и получаем набор всех деталей, входящих в агрегат УУУ.

Но, производитель использует деталь ХХХ в нескольких агрегатах.

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

В иерархии все понятно. Вот у нас таблица строк иерархии с CategoryID.
Вот у нас таблица номенклатур с ItemID.
И вот у нас связывающая таблица с полями CategoryID и ItemID...

В этом случае мы можем устроить отношение многие ко многим.
По одной детали выбрать несколько агрегатов, куда деталь входит.
И по каждому агрегату найти эту деталь в составе агрегата.

Но, как вы, имея только одно поле "агрегат" в записи номенклатуры, собираетесь искать эту запись по разным агрегатам?!
Или нужно на каждый агрегат заводить свое поле?

[mazzy]

Цитата:

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

допустим у вас есть поле в строке номенклатуры
...
Но, производитель использует деталь ХХХ в нескольких агрегатах.

вопрос содержит самопротиворечие.

отношение "деталь используется в нескольких агрегатах" нельзя выразить в ОДНОМ поле ОДНОЙ таблицы.

отношение "деталь используется в нескольких агрегатах" требует подчиненной таблицы. НЕ иерархии, а всего лишь подчиненной. Разницу чувствуете?

поиск по нескольким связанным таблицам в Аксапте - раз плюнуть.

[Narayana]

Цитата:

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

вопрос содержит самопротиворечие.

отношение "деталь используется в нескольких агрегатах" нельзя выразить в ОДНОМ поле ОДНОЙ таблицы.

отношение "деталь используется в нескольких агрегатах" требует подчиненной таблицы. НЕ иерархии, а всего лишь подчиненной. Разницу чувствуете?

поиск по нескольким связанным таблицам в Аксапте - раз плюнуть.

Разницу и чувствую, и не чувствую... )

Для начала хорошо было бы разобраться со смыслом слова "иерархия".

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

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

Мне сдается, что вас-то как раз раздражает не сама возможность существования логической иерархии, реализованной записями в таблицах, а медленность работы TreeView.
Но, мне тоже кажется, что при небольших размерах таблиц, из которых TreeView стряпается, это не такое уж большое зло. Тем более, что, например, справочник ГРУПП продукции торговой или производственной компании, которому нужно сопоставить линейный список номенклатур, заведомо не может быть очень большим.
То есть, сами номенклатуры показывать деревом, это плохо, а вот собственные номенклатурные группы, это хорошо.

Так?

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

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.