AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 26.07.2013, 12:08   #1  
Narayana is offline
Narayana
Участник
 
241 / 100 (4) +++++
Регистрация: 05.01.2009
Адрес: Москва
Использование TreeView в Ax2009
Всем привет!

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

В общем, интересны следующие моменты:
- является ли этот инструмент рабочим? Можно ли эффективно создавать узлы с названиями, взятыми из самосвязанной таблицы, устроенной по принципу KeyFieldId + ParentKeyFieldId ?
- какова типичная техника создания узлов дерева. С первого взгляда не видно класса TreeViewCollection и некоторых других классов, типичных для .Net
- была ли у кого-нибудь успешная попытка создания формы, где слева были бы категории номенклатур, а справа грид с номенклатурами, соответствующими выбранному узлу? И если кто-то это делал, насколько быстро работает?
Старый 26.07.2013, 12:14   #2  
user_ax is offline
user_ax
Участник
Аватар для user_ax
 
599 / 39 (3) +++
Регистрация: 07.10.2012
Адрес: ZP
Почитайте, будет полезно

Строим дерево
Старый 26.07.2013, 12:37   #3  
ansoft is offline
ansoft
Участник
Аватар для ansoft
 
123 / 37 (2) +++
Регистрация: 20.10.2005
Цитата:
TreeView*** в Ax 2009
Много где используется в Ax 2009... даже в стандарте...
А приминительно к номенклатурному справочнику у нас иерархия приехала вместе с одним из проектов АНД...
АНД очень любит иерархические справочники, у них собственная разработка с настройками и т.п. и т.д.
На номенклатурном справочнике работает неплохо, хотя мы активно не используем...
Привлекает то, что при включении иерархии грид не пропадает, а фильтруется в соответствии с узлом и можно добавлять по правой кнопке мыши в дереве...
Старый 26.07.2013, 12:44   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Narayana Посмотреть сообщение
но все-таки иерархии номенлатур, штука очень нужная и если делать справочник товаров по человечески, без нее никак не обойдешься.
Нет, иерархия - штука не нужная, мало того, вредная (когда в единственном числе).
справочник товаров по человечески - это линейный список с удобной фильтрацией по любому реквизиту.

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

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

Очень жаль, что в акс2012 пошли по пути иерархий (множественное число!), а не развивали отборы.
На мой взгляд это влияние менее развитых GP и SL на единый интерфейс всех Dynamics систем.
Старый 26.07.2013, 12:46   #5  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ansoft Посмотреть сообщение
А приминительно к номенклатурному справочнику у нас иерархия приехала вместе с одним из проектов ...
чтобы обсуждение не привязывать к конкретному проекту и конкретному внедренцу...
лучше посмотреть обсуждения открытого проекта
Абстрактный классификатор (версия 1.0)
Абстрактный классификатор (версия 1.1)

и так далее по ключевым словам "абстрактный классификатор"
Старый 26.07.2013, 12:48   #6  
ansoft is offline
ansoft
Участник
Аватар для ansoft
 
123 / 37 (2) +++
Регистрация: 20.10.2005
Касательно идеи... то можно реализовать примерно как поле в ном. справочнике - группа для иерархии, привязанное к справочнику групп с возможностью ссылки на родительскую группу (по практике Аксапты из этого же справочника, главное не зациклить ).
Далее в форме номенклатурного справочника галку для иерархии, Tree, Splitter. Прячем Tree и показываем по галке... Загрузку в дерево либо при открытии, либо по галке. По событию тыка в узел executeQuery на InventTable наложением фильтров. На Create прописывать поле группы, на правую кнопку Tree - возможность добавлять группу... Далее если поудобнее, то не прятать поле группы иерархии в гриде и навесить на него лукап с тем же Tree чтобы номенклатуру можно было перекинуть в другую группу прямо в строке или при скрытом поле, кнопку переместить в группу... и т.д. и т.п.
Работать должно нормально для приемлемого кол-ва групп...
Старый 26.07.2013, 12:58   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Посмотреть реализацию лучше на модуле проектов в Аксапте. Форма со списком проектов.

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

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

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

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

иерархии "как в 1С" нормально работают только на игрушечных наборах данных до сотен тысяч записей. На больших объемах иерархии умирают. Как на концептуальном уровне, так и на техническом.
Старый 26.07.2013, 15:52   #8  
ansoft is offline
ansoft
Участник
Аватар для ansoft
 
123 / 37 (2) +++
Регистрация: 20.10.2005
Цитата:
Это как раз тот ТЕХНИЧЕСКИЙ момент, который делает дерево таким неудобным в разработке на реальных проектах с неигрушечными объемами. (дополнительно к концептуальным)
Цитата:
См. форму с правами доступа - каждый раз при открытии этой формы убить хочется того, кто сделать загрузку дерева при открытии.
Если делать иерархию подобную дереву с правами, то кому она нужна?
Борода отрастет пока в дереве найдешь необходимый узел...
Скромный набор групп позволит грузить его быстро без expand, при желании с кэшированием.
Конечно если пустить строить группы пользователя(ей), которые кто в лес, кто по дрова, то "копец"

Цитата:
Работать должно нормально для приемлемого кол-ва групп...
Скромная иерархия,по-моему мнению, вполне может иметь место, что позволит быстрее делить массив данных с
Цитата:
неигрушечными объемами
по клику визуально, не лазая в колбочки с написанием *куска группы*, фильтры посетке с написанием *куска группы*, а если фильтр по правой кнопке, то вначале надо встать на позицию, по которой будем фильтровать... и т.д. и т.п.
Старый 26.07.2013, 22:35   #9  
Narayana is offline
Narayana
Участник
 
241 / 100 (4) +++++
Регистрация: 05.01.2009
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
Нет, иерархия - штука не нужная, мало того, вредная (когда в единственном числе).
справочник товаров по человечески - это линейный список с удобной фильтрацией по любому реквизиту.

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

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

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

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

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

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

Последний раз редактировалось Narayana; 26.07.2013 в 22:38.
Старый 26.07.2013, 22:49   #10  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Narayana Посмотреть сообщение
допустим у вас есть поле в строке номенклатуры
...
Но, производитель использует деталь ХХХ в нескольких агрегатах.
вопрос содержит самопротиворечие.

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

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

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

Старый 29.07.2013, 07:43   #11  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Цитата:
Сообщение от mazzy Посмотреть сообщение
иерархия - штука не нужная
Таки даже в описании таких естественных иерархических структур как штатное расписание и структура холдинга ?
__________________
Мы летаем, кружимся, нагоняем ужасы ...
За это сообщение автора поблагодарили: mazzy (10).
Старый 29.07.2013, 09:10   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Таки даже в описании таких естественных иерархических структур как штатное расписание и структура холдинга ?
э-э-э. подловили.

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

именно для таких структур и стоит использовать TreeView или новый появившийся элемент для отображения и редактирования структуры организации.
Старый 29.07.2013, 09:21   #13  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,765 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Следует поставить под сомнение понятие естественности применимое к иерархическим структурам организации. Так как всё зависит от того, что естественно, а что нет
И уж совершенно точно можно утверждать, что любая орг структура 100% искусственна.
За это сообщение автора поблагодарили: ansoft (1).
Старый 29.07.2013, 18:29   #14  
Narayana is offline
Narayana
Участник
 
241 / 100 (4) +++++
Регистрация: 05.01.2009
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
вопрос содержит самопротиворечие.

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

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

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

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

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

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

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

Так?
Старый 29.07.2013, 18:33   #15  
Narayana is offline
Narayana
Участник
 
241 / 100 (4) +++++
Регистрация: 05.01.2009
Адрес: Москва
Цитата:
Сообщение от Vals Посмотреть сообщение
Следует поставить под сомнение понятие естественности применимое к иерархическим структурам организации. Так как всё зависит от того, что естественно, а что нет
И уж совершенно точно можно утверждать, что любая орг структура 100% искусственна.
...а как же "папа, мама, я, - дружная семья!" ?
Неужто, это искусственная орг структура?
Старый 29.07.2013, 19:11   #16  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Раздражает неудобство работы с клавиатурой (что, впрочем, уже стало нормой в последних версиях AX), и, стало быть, пониженная производительность работы.
Старый 29.07.2013, 20:23   #17  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
К общим рассуждениям о деревьях в Аксе (с которыми я в целом не согласен), я бы добавил задачу по подготовке справочников к использованию в OLAP отчетности, в которой иерархические отчеты практически стандарт де-факто. Т.е. отображение дерева в аксапте можно рассматривать не только как ненужный элемент повседневной работы, но и как предварительный просмотр дерева, которое попадет в OLAP.
__________________
Ivanhoe as is..
Старый 29.07.2013, 20:40   #18  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
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 ничего не вызывает. Зачем? Ну зачем они это сделали? Не используется ведь... Столько места бестолку занимает...
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 29.07.2013, 20:45   #19  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
К общим рассуждениям о деревьях в Аксе (с которыми я в целом не согласен),
Э... С какими именно?..

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

Для OLAP-отчетов, как правило, детали не так уж и важны. Интерес представляют именно группы. А для повседневной работы нужны именно детали, а всякие там группы, если и имеют какое-то значение, то далеко не первостепенное.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 29.07.2013, 22:30   #20  
Narayana is offline
Narayana
Участник
 
241 / 100 (4) +++++
Регистрация: 05.01.2009
Адрес: Москва
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
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 запрос, - не понятна большинству.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
ax2009: сервер постоянно что-то делает. почему? mazzy DAX: Администрирование 28 01.06.2016 16:58
axinthefield: Choosing a Single Deployment or Multiple Deployments of AX2009 Blog bot DAX Blogs 0 15.06.2011 03:25
sumitax: SharePoint 2010 and AX2009 Blog bot DAX Blogs 0 11.11.2010 11:11
Shekhar: Dynamics AX2009 : Standalone Installation on Vista with Role centres and workflow. Blog bot DAX Blogs 0 30.03.2010 15:05
Amand: Использование партнёрских решений и их совместимость в разных версиях Axapta 3.0, Dynamics AX 4.0 и AX2009 Blog bot DAX Blogs 0 08.03.2009 22:09
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:17.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.