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

[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С.
Другой вопрос, что реализация ТриВью в Аксапте оставляет мало шансов для нормальной работы такой формы.

[AngelDominantes]

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

[mazzy]

Цитата:

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

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

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

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

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

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

[Stitch_MS]

Форма CostSheetDesigner

[mazzy]

Цитата:

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

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

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

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

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

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

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

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

Цитата:

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

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

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

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

[mazzy]

Цитата:

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

Форма CostSheetDesigner

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

[egorych]

Цитата:

Сообщение от 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).
Сводные таблицы просто неправильно работают, если подсунуть им граф вместо дерева.

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

[mazzy]

Цитата:

Сообщение от George Nordic

Хдавай возьмем для примера его.

Ой, а давай не будем сводить к частным случаям?

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

Цитата:

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

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

[Ivanhoe]

Цитата:

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

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

Вы, наверное, про обычные сводные таблицы Excel без OLAP говорите? Там дерево построить, действительно, тяжело. В чем проблема для OLAP и последних версий Excel?

Насчет фильтров и дерева. Не работал с 1С, но кто мешает выбрать в дереве самый первый родительский объект, который покажет именно все записи?

[mazzy]

Цитата:

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

Вы, наверное, про обычные сводные таблицы Excel без OLAP говорите?

Э-э-э...вроде про ОЛАП говорим.

Цитата:

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

Там дерево построить, действительно, тяжело. В чем проблема для OLAP и последних версий Excel?

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

Поясняю:
В частности ОЛАП не проверяет глубину дерева (если ему скормить parentID, ChildID). Что чревато отказами при обходе в глубину.

ОЛАП не будет проверять, что ему подсунули граф, а не дерево. В лучшем случае он просто будет агрегировать (суммировать) несколько раз. В худшем - зациклится.

Следовательно валидация - задача программиста.
Я повторю свою мысль: Как правило, наличие дерева означает что есть очень жесткие ограничения, которые скорее всего противоречат реальной жизни.

Цитата:

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

Насчет фильтров и дерева. Не работал с 1С, но кто мешает выбрать в дереве самый первый родительский объект, который покажет именно все записи?

Во-первых, это надо программировать.
Таких тонких моментов, которые "надо программировать" с деревом очень много.
Поэтому я и говорил про "усложнение на порядок".

Во-вторых, "первый родительский объект" не решает проблему.
Предположим, что установили на первый родительский объект. Значит ли это, что все найденные "*пальто*" принадлежат родительскому объекту?

[Ivanhoe]

Цитата:

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

Поясняю:
В частности ОЛАП не проверяет глубину дерева (если ему скормить parentID, ChildID). Что чревато отказами при обходе в глубину.

ОЛАП не будет проверять, что ему подсунули граф, а не дерево. В лучшем случае он просто будет агрегировать (суммировать) несколько раз. В худшем - зациклится.

Следовательно валидация - задача программиста.
Я повторю свою мысль: Как правило, наличие дерева означает что есть очень жесткие ограничения, которые скорее всего противоречат реальной жизни.

1. Мне кажется отказ при обходе из-за глубины чем-то напоминает ограничение Excel ..2003 в 64 тыс. строк. Есть такое ограничение, его просто надо иметь в виду. Также как и другие ограничения любой платформы для построения отчетности.
2. Не допускайте графа при создании дерева, вот и вся задача. Понятно, что это надо программировать. Но при этом и понятна выгода от использования агрегированных аналитических отчетов.

Цитата:

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

Во-вторых, "первый родительский объект" не решает проблему.
Предположим, что установили на первый родительский объект. Значит ли это, что все найденные "*пальто*" принадлежат родительскому объекту?

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