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

[AngelDominantes]

Доброго времени суток, возникла необходимость создать дерево, раньше в Аксапте никогда с ними не сталкивался, но имею представление еще по опыту программирования на С++, с чего собственно начать, есть ли какой-то хелп по этому поводу, или хотя бы примеры в стандартном функционале. AX 2009, заранее благодарен!

[Ivanhoe]

Форма tutorial_Form_TreeControl в помощь

[mazzy]

Цитата:

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

Доброго времени суток, возникла необходимость создать дерево, раньше в Аксапте никогда с ними не сталкивался, но имею представление еще по опыту программирования на С++, с чего собственно начать, есть ли какой-то хелп по этому поводу, или хотя бы примеры в стандартном функционале. AX 2009, заранее благодарен!

форма tutorial_Form_TreeControl
форма ProjTable
а самый пример, который наглядно демонстрирует, что деревья использовать НЕ надо - форма SysUserGroupSecurity, вкладка Права.


========================================
Суть вопроса:
дерево - это всего лишь способ фильтрации данных.
Перечитайте еще раз.

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

Дерево - предоставляет единственно возможный способ фильтрации (обратите внимание как извращаются с несколькими способами фильтрации в форме SysUserGroupSecurity)

Вместо дерева ПОЧТИ ВСЕГДА лучше использовать обычные фильтры по разным полям и реквизитам. А это Аксапта замечательно умеет делать в Grid'е
Перечитайте еще раз.

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

========================================
Технический аспект:
аксапта содержит контрол TreeView.
= данные в этот контрол могут загружаться сразу при открытии (что и делает форма SysUserGroupSecurity со всеми вытекающими последствиями для быстродействия)
= данные в этот контрол могут загружаться по мере открытия веток пользователем (что усложняет программирование контрола на порядок)

В ЛЮБОМ СЛУЧАЕ по дереву не предусмотрен интерфейс поиска пользователем.
никакой. ни по какому реквизиту.
Перечитайте в предыдущем абзаце "...то это значит данных достаточно много И пользователю нужно предоставить способ сокращения..."

в результате поиск по дереву придется писать программисту (см. ту же самую злосчастную форму SysUserGroupSecurity), что усложняет программирование контрола еще на два порядка.

========================================
Поэтому:
если у вас "возникла необходимость создать дерево" - измените техзадание и работайте с гридом ПЛЮС дайте пользователям возможность быстрой фильтрации.

Возможно, для этого вам придется пересмотреть структуру таблиц.

========================================
мое личное бурчание, возможно не имеющее никакого отношения к вам:
мой опыт подсказывает, что как только у кого-то "возникла необходимость создать дерево", то это первый признак того, что структура данных, заложенная архитектором-программистом, не совпадает со структурой реальных данных, которые находятся в голове у пользователей. Другими словами, запрограммировано не то, что ожидается людьми.

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

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

[egorych]

Цитата:

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

мое личное бурчание, возможно не имеющее никакого отношения к вам:
мой опыт подсказывает, что как только у кого-то "возникла необходимость создать дерево", то это первый признак того, что структура данных, заложенная архитектором-программистом, не совпадает со структурой реальных данных, которые находятся в голове у пользователей. Другими словами, запрограммировано не то, что ожидается людьми.

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

Ну зачем так сразу - например, штатное расписание (структура подчинения на фирме) вполне себе ожидается в виде дерева.
Хотя соглашусь, что в большинстве случаев дерево не нужно - просто привычка, заложенная 1С.
Другой вопрос, что реализация ТриВью в Аксапте оставляет мало шансов для нормальной работы такой формы.

[mazzy]

Цитата:

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

Ну зачем так сразу - например, штатное расписание (структура подчинения на фирме) вполне себе ожидается в виде дерева.

Вот как раз штатное расписание - отличный пример НЕ дерева, а графа.

Во-первых,
чтобы представить штатное расписание в виде дерева вводится понятие ставка/полставки/четвертьставки и другие доли ставки. Но параметр ставка как правило не является объективным параметром. это как правило чисто волевой параметр - "так решили". Если же смотреть дальше, то представление штатного расписания в виде дерева предельно усложняет жизнь на следующих уровнях обработки информации - так один человек может принадлежать нескольким элементам штатного расписания. Таким образом, граф просто выметается из одного объекта и переносится в другой.

Во-вторых, в общем случае, штатное расписание помимо простого "иерерхического" может быть матричным, может быть проектным и другим произвольным ГРАФОМ.

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

[egorych]

Цитата:

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

Вот как раз штатное расписание - отличный пример НЕ дерева, а графа.

Во-первых,
чтобы представить штатное расписание в виде дерева вводится понятие ставка/полставки/четвертьставки и другие доли ставки. ...

Ну это страсти так сказать "в общем случае". ИМХО в большинстве частных случаев дерево вполне нормально работает. Ну по крайней мере в моей практике.

[AngelDominantes]

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

[mazzy]

Цитата:

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

Все таки в моем случае актуальнее использовать дерево, элементов в дереве будет достаточно мало порядка 20-30

Как раз для 20-30 элементов дерево - предельно НЕ актуально.
Но как скажете.

AngelDominantes, еще раз повторю (вы похоже не обратили внимания):
= дерево - это всего лишь способ фильтрации
= дерево - это единственный способ фильтрации для всех пользователей

если вы будете использовать этот "эстетичный" способ, вам неизбежно придется запретить ЛЮБЫЕ способы фильтрации данных, помимо дерева.
Другими словами, выбирая "эстетичный" способ - вы лишаете пользователей возможностей поиска и фильтрации.

Добавил: подумайте почему 1Су пришлось реализовать режим работы "без иерархии" и обратите внимание насколько не "эстетично" выглядит и работает дерево в этом режиме.

(Убил бы того, кто сделал форму SysUserGroupSecurity в виде дерева)

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

Цитата:

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

Все таки в моем случае актуальнее использовать дерево, элементов в дереве будет достаточно мало порядка 20-30, то есть в дереве будут находиться элементы, содержание которых будет отображаться в гриде рядом, конечно можно использовать 2 грида, но вариант с деревом выглядит эстетичнее.

Ну..ну, подождите, пока Вас попросят сделать отчет по отображаемой структуре. Вот тогда и поговорим об "эстетике" Это еще не считая слова mazzy о реализации поиска и фильтрации в этой самой "эстетичной" форме...

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

[George Nordic]

Цитата:

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

Ну..ну, подождите, пока Вас попросят сделать отчет по отображаемой структуре. Вот тогда и поговорим об "эстетике"

Ну или делать как отчет по оргструктуре - через жWord.

Начет мины - согласен. Только на нее может и еще кто-то наступить. Делайте гридом, но оставите галку "отобразить в виде дерева" как проекты. Дисциплинурует. Плюс - все действия осуществлять на гриде. А в виде дерева - только отображать. Спасет от баловства с драг н дроп, куче программирования, 2х деревьев для сотрировки "не туда попавших итемов" и написание небольшого тотал командера в АХ.

С Уважением,
Георгий

[Ivanhoe]

Цитата:

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

если вы будете использовать этот "эстетичный" способ, вам неизбежно придется запретить ЛЮБЫЕ способы фильтрации данных, помимо дерева.
Другими словами, выбирая "эстетичный" способ - вы лишаете пользователей возможностей поиска и фильтрации.

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

Цитата:

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

Ну..ну, подождите, пока Вас попросят сделать отчет по отображаемой структуре. Вот тогда и поговорим об "эстетике" Это еще не считая слова mazzy о реализации поиска и фильтрации в этой самой "эстетичной" форме...

Поясните, в чем проблема фильтрации?

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

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

[George Nordic]

Цитата:

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

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

Хм. А вот тут бы поспорил. У вас же решение для розницы - давай возьмем для примера его. Есть требование заказчика: отобразить все товары в виде дерева. Ок, делаем. Приходят продуктовые и давай тербовать: а почему не в разрезе категорий? А почему не в разрезе брендов? А почему не в разрезе магазинов / полок? А как отобразить в виде дерева решенией? И пошло-поехало.

С Уважением,
Георгий

[mazzy]

Цитата:

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

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

э-э-э... а где я говорил, что фильтры не могут жить ВМЕСТЕ?
я говорил, "что придется запретить ЛЮБЫЕ способы фильтрации данных, помимо дерева."
вы спрашиваете совершенно про другое.

Чтобы пояснить свою мысль, привожу скриншоты из 1С, где дерево уже есть.

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

можно даже добавлять фильтры ДОПОЛНИТЕЛЬНО к фильтрации по дереву (другими словами фильтры МОГУТ жить вместе).

другое дело, что при фильтрации по дереву, пользователи не могут найти ВСЕ элементы... бла-бла-бла-читайте-на-форумах-про-1С... поэтому разработчики 1С ввели режим с выключенной иерархией (фильтрация по дереву ВЫКЛЮЧЕНА, видны все элементы списка несмотря на контрол дерево)


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

ПОЭТОМУ, как я и говорил "придется запретить ЛЮБЫЕ способы фильтрации данных, помимо дерева".
либо выключить дерево полностью в режиме "без иерархии"
либо смириться с гадостью, которая есть в 1Се...

если же контрол дерево полностью выключить (как в модуле Проекты), то дерево вообще не нужно (и не нужно тратить время на код вокруг этого контрола)

==================
Ключевой вопрос - можно ли пользователям обойтись БЕЗ режима "без иерархии". Как видите, разработчики 1С вынуждены были такой режим предусмотреть.

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

[mazzy]

Цитата:

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

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

Как раз для работы сводных таблиц и тем более иерархий - деревья противопоказаны.

Я об этом писал

Цитата:

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

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

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

В реальной жизни чистое дерево бывает очень редко. Как правило, наличие дерева означает что есть очень жесткие ограничения, которые скорее всего противоречат реальной жизни.

[Stitch_MS]

Форма CostSheetDesigner

[mazzy]

Цитата:

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

Форма CostSheetDesigner

точно.
а также BOMDesigner.

[George Nordic]

А я бы добавил про вариативность: ряд товаров можно отнести к нескольким категориям. И только "хранители знаний" смогут точно определить раздел. Остальные будут кидать новый товар туда, куда, по их мнению, его место. Следовательно в этой категории его не будут искать другие, у которых свое отношение на счет того, чье где место. Я приводил как-то пример с памятью для ноутбука, она могла быть в 4-5 местах прайса, не буду повторяться.
В вашем случае: а куда определеть элетропилу? Электроинструмент или садовая техника? А мин вата - это шумоизоляция или теплоизоляция? ДВП - это ДСП или отделка? А почему?

С Уважением,
Георгий

[AlGol]

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

Ну вот все было нормально, работали в форме и работали. А теперь мучаюсь - может попробовать переделать?

[mazzy]

Цитата:

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

А может кому-то реально неудобно?
Ну вот все было нормально, работали в форме и работали. А теперь мучаюсь - может попробовать переделать?

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


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

===================
я что хочу сказать

Цитата:

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

дерево - это всего лишь способ фильтрации данных.

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

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

[AngelDominantes]

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