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

[Narayana]

Всем привет!

Прошу поделиться мнением тех, кто пользовался классами TreeView*** в Ax 2009.
Судя по всему, этот контрол не получил широкого распространения в парадигме программирования на Аксапте, но все-таки иерархии номенлатур, штука очень нужная и если делать справочник товаров по человечески, без нее никак не обойдешься. Впрочем, если кто-то считает, что можно обойтись, тоже было бы очень интересно послушать.

В общем, интересны следующие моменты:
- является ли этот инструмент рабочим? Можно ли эффективно создавать узлы с названиями, взятыми из самосвязанной таблицы, устроенной по принципу KeyFieldId + ParentKeyFieldId ?
- какова типичная техника создания узлов дерева. С первого взгляда не видно класса TreeViewCollection и некоторых других классов, типичных для .Net
- была ли у кого-нибудь успешная попытка создания формы, где слева были бы категории номенклатур, а справа грид с номенклатурами, соответствующими выбранному узлу? И если кто-то это делал, насколько быстро работает?

[user_ax]

Почитайте, будет полезно

Строим дерево

[ansoft]

Zitat:

TreeView*** в Ax 2009

Много где используется в Ax 2009... даже в стандарте...
А приминительно к номенклатурному справочнику у нас иерархия приехала вместе с одним из проектов АНД...
АНД очень любит иерархические справочники, у них собственная разработка с настройками и т.п. и т.д.
На номенклатурном справочнике работает неплохо, хотя мы активно не используем...
Привлекает то, что при включении иерархии грид не пропадает, а фильтруется в соответствии с узлом и можно добавлять по правой кнопке мыши в дереве...

[mazzy]

Zitat:

Zitat von Narayana

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

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

http://axapta.mazzy.ru/lib/tree/

Единственная иерархия - это тупо "как в 1С".
постановщику достаточно сказать "делайте как в 1С" и уже ни о чем думать не надо

Очень жаль, что в акс2012 пошли по пути иерархий (множественное число!), а не развивали отборы.
На мой взгляд это влияние менее развитых GP и SL на единый интерфейс всех Dynamics систем.

[mazzy]

Zitat:

Zitat von ansoft

А приминительно к номенклатурному справочнику у нас иерархия приехала вместе с одним из проектов ...

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

и так далее по ключевым словам "абстрактный классификатор"

[ansoft]

Касательно идеи... то можно реализовать примерно как поле в ном. справочнике - группа для иерархии, привязанное к справочнику групп с возможностью ссылки на родительскую группу (по практике Аксапты из этого же справочника, главное не зациклить ).
Далее в форме номенклатурного справочника галку для иерархии, Tree, Splitter. Прячем Tree и показываем по галке... Загрузку в дерево либо при открытии, либо по галке. По событию тыка в узел executeQuery на InventTable наложением фильтров. На Create прописывать поле группы, на правую кнопку Tree - возможность добавлять группу... Далее если поудобнее, то не прятать поле группы иерархии в гриде и навесить на него лукап с тем же Tree чтобы номенклатуру можно было перекинуть в другую группу прямо в строке или при скрытом поле, кнопку переместить в группу... и т.д. и т.п.
Работать должно нормально для приемлемого кол-ва групп...

[mazzy]

Посмотреть реализацию лучше на модуле проектов в Аксапте. Форма со списком проектов.

Zitat:

Zitat von ansoft

Загрузку в дерево либо при открытии, либо по галке.

Это как раз тот ТЕХНИЧЕСКИЙ момент, который делает дерево таким неудобным в разработке на реальных проектах с неигрушечными объемами. (дополнительно к концептуальным)

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

Нужно загружать дерево по мере открытия веток пользователем.
Аксапта позволяет перехватывать события expand для ветки. Но как же мало реальных программистов, которые этим реально заморачиваются...

а ведь есть еще понятие "поиск" в иерархии...

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

[ansoft]

Zitat:

Это как раз тот ТЕХНИЧЕСКИЙ момент, который делает дерево таким неудобным в разработке на реальных проектах с неигрушечными объемами. (дополнительно к концептуальным)

Zitat:

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

Если делать иерархию подобную дереву с правами, то кому она нужна?
Борода отрастет пока в дереве найдешь необходимый узел...
Скромный набор групп позволит грузить его быстро без expand, при желании с кэшированием.
Конечно если пустить строить группы пользователя(ей), которые кто в лес, кто по дрова, то "копец"

Zitat:

Работать должно нормально для приемлемого кол-ва групп...

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

Zitat:

неигрушечными объемами

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

[Narayana]

Zitat:

Zitat von mazzy

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

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

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

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

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

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

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

[mazzy]

Zitat:

Zitat von Narayana

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

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

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

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

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

[TasmanianDevil]

Zitat:

Zitat von mazzy

иерархия - штука не нужная

Таки даже в описании таких естественных иерархических структур как штатное расписание и структура холдинга ?

[mazzy]

Zitat:

Zitat von TasmanianDevil

Таки даже в описании таких естественных иерархических структур как штатное расписание и структура холдинга ?

э-э-э. подловили.

естественные иерархические структуры конечно же лучше отображать деревом.
но, как правило, естественные иерархические структуры небольшие с точки зрения баз данных (содержат менее 100500+ элементов).

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

[Vals]

Следует поставить под сомнение понятие естественности применимое к иерархическим структурам организации. Так как всё зависит от того, что естественно, а что нет
И уж совершенно точно можно утверждать, что любая орг структура 100% искусственна.

[Narayana]

Zitat:

Zitat von mazzy

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

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

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

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

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

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

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

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

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

Так?

[Narayana]

Zitat:

Zitat von Vals

Следует поставить под сомнение понятие естественности применимое к иерархическим структурам организации. Так как всё зависит от того, что естественно, а что нет
И уж совершенно точно можно утверждать, что любая орг структура 100% искусственна.

...а как же "папа, мама, я, - дружная семья!" ?
Неужто, это искусственная орг структура?

[EVGL]

Раздражает неудобство работы с клавиатурой (что, впрочем, уже стало нормой в последних версиях AX), и, стало быть, пониженная производительность работы.

[Ivanhoe]

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

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

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

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

Zitat:

Zitat von Ivanhoe

К общим рассуждениям о деревьях в Аксе (с которыми я в целом не согласен),

Э... С какими именно?..

Zitat:

Zitat von Ivanhoe

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

Есть существенная разница между повседневной работой и аналитическими отчетами.

Для OLAP-отчетов, как правило, детали не так уж и важны. Интерес представляют именно группы. А для повседневной работы нужны именно детали, а всякие там группы, если и имеют какое-то значение, то далеко не первостепенное.

[Narayana]

Zitat:

Zitat von Владимир Максимов

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