Место общения программистов, форум разработчиков БД на Clarion
https://www.forum.clarionlife.net/
Вот я тоже удивляюсь, Kreator. Одна, не вполне удачная, как я понимаю, реализация (но там шаблон, возможно по-другому его было не написать), накладывает отпечаток на принятие современного решения.kreator писал(а):Удивлён. Всегда думал, что дерево по одному файлу актуальная вещь. Например, в торговых системах. Удобная группировка товара. Опять же, можно аналитику делать по определённому уровня. Ещё пример. Вот сейчас у меня в проекте орг. структура предприятия выложена таким образом (филиалы-цеха-участки-бригады).
Посмотрел класс/шаблон UltraTree, поддержка дерева только через алиасы. Получается - тоже неактуально для народа.
Склоняюсь тогда о реализации через алиасы и шаблон SV дерева, но алиасы попробовать делать не на каждый уровень, а циклически связать два-три алиаса. Посмотрел на свои данные. 5-6 уровней - ещё реально, а больше уже нет. Думаю вероятность использования больше десяти уровней близка к нулю.
Зачем? для апдейта тож не надоShur писал(а):kreator писал(а):...Если реализовывать механизм руками, то я в упор здесь не вижу никаких множественных алиасов (кроме, возможно, одного -- для апдейта)...
, ну и никто не мешает сделать/оставить в шаблоне возможность вставки кода для дальнейшего ручного шлифования/манипулирования в разных вариациях/ситуациях...Использую этот шаблон, всё тоже самое. Но меня напрягает отсутствие интеграции с ABC-классами, плюс напрягает принципиально другое программирование (если сделал и забыл - это одно, а если часто приходится что-то изменять?), плюс напрягает периодически выскакивающие ниоткуда глюки, в т.ч. при смене версий Клариона (подозреваю, что опять же из-за плохой совместимости с ABC). Как пример, недавно столкнулся, что описание очередей шаблон лепит в модульные переменные, и, если в модуле две процедуры с этим шаблоном, то проблема обеспечена. А так шаблон продвинутый, продуманный и функциональный, ничего не могу сказать. По факту, хотелось бы заменить его чем-то более новым, либо вовсе отказаться в пользу какого-то другого решения (как вариант - RelationTree от SV с алиасами).Олег писал(а):Использую еще с пятерки доработанный контрол SingleFileTree из ШВС. Сейчас использую в девятке, немного "допиленные" для работы с SQL.
Код: Выделить всё
SQL_FILE{PROP:SQL}='SELECT t1.PLACEINSTALL AS lvl1, t1.IDPLACE AS ID1, t1.PARENTID AS PD1, ' & |
't2.PLACEINSTALL AS lvl2, t2.IDPLACE AS ID2, t2.PARENTID AS PD2, ' & |
't3.PLACEINSTALL AS lvl3, t3.IDPLACE AS ID3, t3.PARENTID AS PD3, ' & |
't4.PLACEINSTALL AS lvl4, t4.IDPLACE AS ID4, t4.PARENTID AS PD4, ' & |
't5.PLACEINSTALL AS lvl5, t5.IDPLACE AS ID5, t5.PARENTID AS PD5, ' & |
't6.PLACEINSTALL AS lvl6, t6.IDPLACE AS ID6, t6.PARENTID AS PD6, ' & |
't7.PLACEINSTALL AS lvl7, t7.IDPLACE AS ID7, t7.PARENTID AS PD7' & |
' FROM PlacesInst AS t1' & |
' LEFT JOIN PlacesInst AS t2 ON t2.PARENTID = t1.IDPLACE ' & |
' LEFT JOIN PlacesInst AS t3 ON t3.PARENTID = t2.IDPLACE ' & |
' LEFT JOIN PlacesInst AS t4 ON t4.PARENTID = t3.IDPLACE ' & |
' LEFT JOIN PlacesInst AS t5 ON t5.PARENTID = t4.IDPLACE ' & |
' LEFT JOIN PlacesInst AS t6 ON t6.PARENTID = t5.IDPLACE ' & |
' LEFT JOIN PlacesInst AS t7 ON t7.PARENTID = t6.IDPLACE ' & |
' WHERE t1.PARENTID = 0 '
Код: Выделить всё
Li:PlaceInstall=SQL:COL_i+1
Li:IdPlace=SQL:COL_i+2
Li:ParentID=SQL:COL_i+3