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

[mazzy]

Цитата:

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

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

Можно я настойчиво повторю свою мысль?

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

[George Nordic]

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

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

[AlGol]

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

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

[Ivanhoe]

Картинку покажите? может и правда, там удобно все?

[mazzy]

Цитата:

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

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

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


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

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

Цитата:

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

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

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

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

[AngelDominantes]

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

[mazzy]

Цитата:

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

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

см. форму projTable

[mazzy]

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

итак.
1. на форме должы быть обычные табличные датасоры
2. один из самых верхних датасорсов должен "соответствовать" элементам дерева
3. на treeView перехватываете метод selectionChanged
4. в котором так или иначе вызываете метод table_ds.findRecord

метод findRecord выполняет позиционирование датасорса.
И изменение всех подчиненных датасорсов. что неизбежно отобразится на форме.

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

пример того, как это работает см. в форме projTable

[AngelDominantes]

Цитата:

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

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

итак.
1. на форме должы быть обычные табличные датасоры
2. один из самых верхних датасорсов должен "соответствовать" элементам дерева
3. на treeView перехватываете метод selectionChanged
4. в котором так или иначе вызываете метод table_ds.findRecord

метод findRecord выполняет позиционирование датасорса.
И изменение всех подчиненных датасорсов. что неизбежно отобразится на форме.

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

пример того, как это работает см. в форме projTable

А если запись не одна, а скажем в гриде должны отображаться элементы которые соответствую критерию выбора в дереве. То есть надо выполнять table_ds.executeQuery ? если да, то как связать запрос с дата соурсом?

[AlGol]

Цитата:

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

Картинку покажите? может и правда, там удобно все?

Извини, не покажу. Основу составляют данные заказчиков, и выкладывать это на широкое обозрение не буду.

Но в приципе все просто:
- форма трекера задач
- слева в дереве заказчики и статусы задач как первый и второй уровень дерева.
- справа в гриде собственно список задач.

Удобно, как я понимаю (теперь то я задумался об этом...) потому, что все элементы первого уровня легко умещаются на одном экране - соответственно получается типа панель быстрого доступа, в которой легко можно перепрыгнуть с задач Заказчика 1 в разработке к запланированным для Заказчика 2.

[mazzy]

Цитата:

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

То есть надо выполнять table_ds.executeQuery ?

можно и так. но это закат солнца вручную.

ваше дерево наверняка имеет соответствие 1:1 в какой-то таблице. так?
вот эту таблицу и помещаете как ведущий датасорс формы.

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

поэтому позиционировать из treeView надо только одну таблицу - главную.
остальные отфильтруются сами как в master/detail форме.

(при этом в отличие от master/detail грид главной таблицы можно не показывать)

[mazzy]

Цитата:

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

поэтому позиционировать из treeView надо только одну таблицу - главную.
остальные отфильтруются сами как в master/detail форме.

другими словами.
нарисуйте сначала нормальную master/detail форму (это делается легко и просто. и безо всякого программирования)
потом вместо master-грида используйте treeView.
вот и весь секрет.

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

Цитата:

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

Удобно, как я понимаю (теперь то я задумался об этом...) потому, что все элементы первого уровня легко умещаются на одном экране - соответственно получается типа панель быстрого доступа, в которой легко можно перепрыгнуть с задач Заказчика 1 в разработке к запланированным для Заказчика 2.

Угу. "Дерево" - это как каменный цветок. Красиво и удобно. Но! Если элементов не очень много и вносить изменения в структур надо не часто. А то замаешся молотком махать Да и чем больше "размерчик" (количество элементов), тем тяжелее эту "глыбищу" вертеть

[Ivanhoe]

Цитата:

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

можно и так. но это закат солнца вручную.

ваше дерево наверняка имеет соответствие 1:1 в какой-то таблице. так?
вот эту таблицу и помещаете как ведущий датасорс формы.

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

Речь, наверное, про ситуацию, когда надо показать только те элементы подчиненных таблиц, которые соответствуют только текущему выбранному уровню дерева? Без подчиненных? Если нужны подчиненные, то без executeQuery() не обойтись. Или я не прав?

[mazzy]

Цитата:

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

Речь, наверное, про ситуацию, когда надо показать только те элементы подчиненных таблиц, которые соответствуют только текущему выбранному уровню дерева?

В общем случае, Да.
С деревом программировать придется много. Очень много.

[niksen]

ох уж это дерево.... я думаю, мой вопрос вам понравится не меньше:
На форме спланированные заказы-развёртывание строится дерево по конкретному заказу и через кнопку настройки можно указать то, что будет видно в данном дереве. Я хочу добавить туда некоторые поля из InventTable, ну нравятся они мне, так приятнее. Для этого в форме настроек добавляем новое поле в TmpReqExplosionTree, затем новый пункт, например пусть это будет DisplayItemNameAlias. В форму развёртывания добавляем источник данных InventTable... а дальше? в туториале ничего толком об этом нет, к сожалению...
Ну даже если я хочу жёстко прописать отображение какого-то поля из нового источника данных не из формы настроек, а вообще, откуда-то из связанной таблицы - с этим деревом можно с ума сойти... у него же нет источника, всё так жёстко, никакой фильтрации нет...

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