Jump to content




Photo

Hierarchy Manager


11 replies to this topic

#1 Igor Erokhin

Igor Erokhin

    Active Member

  • Moderators
  • Tekla Maintenance Users, Tedds Maintenance Users, Structural Designer Maint. Users, Tekla UFP Users, Tekla EPM Maintenance Users
  • 167 posts

Posted 09 November 2021 - 02:19 PM

Hierarchy Manager

 

Приложение предназначено для создания иерархий неограниченного уровня вложенности.

 

Приложение находится в разработке, оставляйте свои отзывы и предложения.



#2 Pavel Nedviga (106335)

Pavel Nedviga (106335)

    New Member

  • Members
  • Tekla Maintenance Users
  • 11 posts

Posted 09 November 2021 - 06:13 PM

Привет!

 

Отличное начало! Посмотрел! 

Сразу озвучу предложения:

  1. Где-то подсветить HierarchicDefinition GUID. прямо "копируемым" сделать. 
  2. Завести стандартные Иерархические деревья, чтобы уже сейчас пользователи начали понимать, зачем это приложение. 
  3. Сделать Кастом-атрибуты для доступа к стандартным "иерархическим деревьям" (например КСИ, Ведомость элементов, категории ТСС). Там придется жестко зафиксировать и зарезервировать имена или GUID для HierarchicDefinition. Но это нужно сделать сейчас. Иначе пользователи начнут сами изобретать и в конце-концов будет бардак...
  4. Зафиксировать как минимум название UDA атрибута для "описания класса/категории". И чтобы он создавался при генерации нового узла дерева.
  5. Можно обойтись без YAML? Вроде в него ничего сверхсложного не прописано. А вот первые "деревья" возможно стоит поставлять в JSON/YAML/что-то еще (п.2 этого списка). Может даже отдельными TSEP или интегрировать напрямую с API КСИ. Надо еще подумать.

Начало положено...



#3 Artem Terekhov (152852)

Artem Terekhov (152852)

    New Member

  • Members
  • Tekla Maintenance Users, Tekla UFP Users
  • 20 posts

Posted 10 November 2021 - 06:49 AM

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

  1. Кнопка "Применить"  - в концепции работы паттерна MVVM она не обязательна, и , на мой взгляд, ограничивает функционал: например она обновляет сразу несколько свойств, кардинально разного назначения, Имя иерархии и UDA поля (Имя - публичное свойство, требует вызова Modify(), UDA поля записываются с помощью метода SetUser...() и не требуют ничего больше.) Есть предложение как ее убрать.
  2. Блокировка поля Имени и Полей UDA. Имя, как выяснилось, нужно блокировать у Иерархий с "детьми" но вот UDA поля точно нет. Их Изменение не ведет к потере "детей", если п.1 реализовать то это легко справить.
  3. Логика работы деревьев Иерархий? Я думал, что "ствол" дерева должен автоматом включать все "листья" и показывать кол-во этих "листьев" на всем дереве. Сейчас получается что "ствол" имеет свои "листья" а "ветки" свои, что противоречит логики  TreeView. Я не знаю ошибка это, или так задумывалось, но я предложил бы рассмотреть возможность Логики как в Организаторе. Аналогично и кол-во должно суммироваться с веток.
  4.  При нажатии кнопки "Обновить" все объекты теряют изменения Имени, скорее всего проблемы с методом Modify().
  5. Export/Import выдает Exceptions, который сразу пропадет и закрывает приложение.
  6. Макрос приложенный для тестирования работает хорошо, но не умеет создавать папку IFC, если ее создать самому то все работает! :)
  7. Самое "слабое" сейчас, на мой взгляд, место - файл YAML, я бы назвал данный файл "Агрессивным". Слишком много на себя берет.  Пока не понимаю изменяет ли кнопка "Применить" данный файл, но скорее всего нет, и получается, что если изменить Имена главных Иерархий, то при повторном открытии они будут потеряны, так как приложение создаст новые иерархии с именами из файла. Так же и в обратную сторону, если Изменить файл, то созданные иерархии с другими именами будут потеряны, это не безопасно.
    Имена иерархий в данном файле являются ключами, при этом нет защиты от дублирования ключей см. фото.
    Решать данные проблемы, возможно лучше коллективно, на мой взгляд, но в любом случае я бы предложил изменить подход к "Стволам" деревьев.
    По регистрации UDA полей других идей нет, кажется это хорошее решение.
    Screenshot 2021-11-10 093821.png


#4 Artem Terekhov (152852)

Artem Terekhov (152852)

    New Member

  • Members
  • Tekla Maintenance Users, Tekla UFP Users
  • 20 posts

Posted 11 November 2021 - 09:12 AM

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

Еще есть вариант просто добавить кнопку +"Создать новое дерево" с именем New.
Спасибо.



#5 Igor Erokhin

Igor Erokhin

    Active Member

  • Moderators
  • Tekla Maintenance Users, Tedds Maintenance Users, Structural Designer Maint. Users, Tekla UFP Users, Tekla EPM Maintenance Users
  • 167 posts

Posted 11 November 2021 - 02:44 PM

Привет!

 

Отличное начало! Посмотрел! 

Сразу озвучу предложения:

  1. Где-то подсветить HierarchicDefinition GUID. прямо "копируемым" сделать. 
  2. Завести стандартные Иерархические деревья, чтобы уже сейчас пользователи начали понимать, зачем это приложение. 
  3. Сделать Кастом-атрибуты для доступа к стандартным "иерархическим деревьям" (например КСИ, Ведомость элементов, категории ТСС). Там придется жестко зафиксировать и зарезервировать имена или GUID для HierarchicDefinition. Но это нужно сделать сейчас. Иначе пользователи начнут сами изобретать и в конце-концов будет бардак...
  4. Зафиксировать как минимум название UDA атрибута для "описания класса/категории". И чтобы он создавался при генерации нового узла дерева.
  5. Можно обойтись без YAML? Вроде в него ничего сверхсложного не прописано. А вот первые "деревья" возможно стоит поставлять в JSON/YAML/что-то еще (п.2 этого списка). Может даже отдельными TSEP или интегрировать напрямую с API КСИ. Надо еще подумать.

Начало положено...

  1. Это сделать легко, но для чего это нужно? Для использования иерархий и определений иерархий в собственных решениях? Можно подробнее?
  2. Стандартные иерархии можно хранить в шаблоне модели или (в будущем) в виде экспортированного файла. Но здесь нужна ваша помощь, как специалистов-практиков. Нужны примеры таких стандартных иерархий.
  3. Это продолжение пункта 2, нужна помощь в разработке стандартных иерархий.
  4. Согласен.
  5. Согласен, что юзер-френдли-подход - это иметь настройки в интерфейсе программы. Будем двигаться в эту сторону. (Наверное, будет что-то типа фронтенда для yaml.)

Спасибо за отзыв!



#6 Igor Erokhin

Igor Erokhin

    Active Member

  • Moderators
  • Tekla Maintenance Users, Tedds Maintenance Users, Structural Designer Maint. Users, Tekla UFP Users, Tekla EPM Maintenance Users
  • 167 posts

Posted 11 November 2021 - 02:59 PM

 

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

  1. Кнопка "Применить"  - в концепции работы паттерна MVVM она не обязательна, и , на мой взгляд, ограничивает функционал: например она обновляет сразу несколько свойств, кардинально разного назначения, Имя иерархии и UDA поля (Имя - публичное свойство, требует вызова Modify(), UDA поля записываются с помощью метода SetUser...() и не требуют ничего больше.) Есть предложение как ее убрать.
  2. Блокировка поля Имени и Полей UDA. Имя, как выяснилось, нужно блокировать у Иерархий с "детьми" но вот UDA поля точно нет. Их Изменение не ведет к потере "детей", если п.1 реализовать то это легко справить.
  3. Логика работы деревьев Иерархий? Я думал, что "ствол" дерева должен автоматом включать все "листья" и показывать кол-во этих "листьев" на всем дереве. Сейчас получается что "ствол" имеет свои "листья" а "ветки" свои, что противоречит логики  TreeView. Я не знаю ошибка это, или так задумывалось, но я предложил бы рассмотреть возможность Логики как в Организаторе. Аналогично и кол-во должно суммироваться с веток.
  4.  При нажатии кнопки "Обновить" все объекты теряют изменения Имени, скорее всего проблемы с методом Modify().
  5. Export/Import выдает Exceptions, который сразу пропадет и закрывает приложение.
  6. Макрос приложенный для тестирования работает хорошо, но не умеет создавать папку IFC, если ее создать самому то все работает! :)
  7. Самое "слабое" сейчас, на мой взгляд, место - файл YAML, я бы назвал данный файл "Агрессивным". Слишком много на себя берет.  Пока не понимаю изменяет ли кнопка "Применить" данный файл, но скорее всего нет, и получается, что если изменить Имена главных Иерархий, то при повторном открытии они будут потеряны, так как приложение создаст новые иерархии с именами из файла. Так же и в обратную сторону, если Изменить файл, то созданные иерархии с другими именами будут потеряны, это не безопасно.
    Имена иерархий в данном файле являются ключами, при этом нет защиты от дублирования ключей см. фото.
    Решать данные проблемы, возможно лучше коллективно, на мой взгляд, но в любом случае я бы предложил изменить подход к "Стволам" деревьев.
    По регистрации UDA полей других идей нет, кажется это хорошее решение.
    attachicon.gifScreenshot 2021-11-10 093821.png

 

 

 

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

Еще есть вариант просто добавить кнопку +"Создать новое дерево" с именем New.
Спасибо.

  1. Согласен.
  2. Надо проверить, если это так, то, конечно, переделаем.
  3. Если я правильно понял, то "ветки" - это дочерние категории, а "листья" - это объекты модели. Т. е., родительский объект должен содержать в себе объекты модели всех входящих в него дочерних объектов?
  4. Исправим.
  5. Исправим.
  6. Тоже исправим.
  7. Кнопка "Применить" не изменяет конфиг-файл, а изменение корневой категории запрещено на уровне кода. По дублированию категорий, согласен, исправим.
    Идея иметь одну суперкорневую иерархию (Project) имеет смысл, но нужны ли нам все псевдокорневые иерархии (которые сейчас задаются в конфиг-файле)? Есть вероятность, что будут существовать иерархии, созданные другими инструментами. Текущий подход позволяет их отфильтровывать.
     
  8. Вопрос уникальности объектов в категориях сейчас никак не решается. Пока непонятно, нужно ли это. Может быть, сделать признак определений иерархий, который определяет, будут ли объекты в его категориях уникальными или нет?

Спасибо за тестирование и предложения!



#7 Artem Terekhov (152852)

Artem Terekhov (152852)

    New Member

  • Members
  • Tekla Maintenance Users, Tekla UFP Users
  • 20 posts

Posted 12 November 2021 - 08:21 AM

Добрый день.
п.3 Да, данное поведение не подразумевается обязательным для данного приложения(Класса HierarchickObject). Но для некоторых случаев, например для классификации объектов по пространству, это сделает дополнительную пользу от приложения(Как в Организаторе), если оно будет уметь следить за этим, чтобы "Листья" включались во все верхние иерархии, и для этого не обязательно включать их в сами иерархии, просто сделать выбор объектов иерархии из детей и детей-детей..
п.7 Возможно, моя идея будет актуально, если сделать checkBox для кнопки создать, который бы переводил режим создания с "Создать внутри" на "Создать рядом". Тогда можно было бы добавлять Иерархии в корень тоже.

UntitledHierarchic.png
п.8 Для некоторых классификаторов данное поведение обязательно, где недопустимо участие одной и той же детали в разных Иерархиях и даже в разных уровнях Иерархии, после определенной вложенности. Возможно, данный вопрос нужно рассмотреть совместно с п.3. Постановка задачи наверно звучит как: все объекты внутри данной категории будут уникальны. п.3 и п.8 можно отнести как свойства категории на ровне с UDA, возможно его можно решить через UDA  и через DataGrid.
9) Чтение yaml файла из папок модели работает хорошо. :) 
10) Вызывает пока интуитивное неудобство, тот факт что все UDA поля объявляются для всех Иерархий, но ведь Иерархии могут отвечать за разные Классификаторы. Нет возможности добавлять собственные UDA поля, хотя DataGrid позволяет это реализовать, но нужно добавить сканирование UDA полей не только из файла, а из Иерархий тоже, получать весть список UDA полей и выводить их в DataGrid для каждой иерархии.
С уважением.
 



#8 Igor Erokhin

Igor Erokhin

    Active Member

  • Moderators
  • Tekla Maintenance Users, Tedds Maintenance Users, Structural Designer Maint. Users, Tekla UFP Users, Tekla EPM Maintenance Users
  • 167 posts

Posted 12 November 2021 - 12:10 PM

Добрый день.
п.3 Да, данное поведение не подразумевается обязательным для данного приложения(Класса HierarchickObject). Но для некоторых случаев, например для классификации объектов по пространству, это сделает дополнительную пользу от приложения(Как в Организаторе), если оно будет уметь следить за этим, чтобы "Листья" включались во все верхние иерархии, и для этого не обязательно включать их в сами иерархии, просто сделать выбор объектов иерархии из детей и детей-детей..
п.7 Возможно, моя идея будет актуально, если сделать checkBox для кнопки создать, который бы переводил режим создания с "Создать внутри" на "Создать рядом". Тогда можно было бы добавлять Иерархии в корень тоже.

attachicon.gifUntitledHierarchic.png
п.8 Для некоторых классификаторов данное поведение обязательно, где недопустимо участие одной и той же детали в разных Иерархиях и даже в разных уровнях Иерархии, после определенной вложенности. Возможно, данный вопрос нужно рассмотреть совместно с п.3. Постановка задачи наверно звучит как: все объекты внутри данной категории будут уникальны. п.3 и п.8 можно отнести как свойства категории на ровне с UDA, возможно его можно решить через UDA  и через DataGrid.
9) Чтение yaml файла из папок модели работает хорошо. :) 
10) Вызывает пока интуитивное неудобство, тот факт что все UDA поля объявляются для всех Иерархий, но ведь Иерархии могут отвечать за разные Классификаторы. Нет возможности добавлять собственные UDA поля, хотя DataGrid позволяет это реализовать, но нужно добавить сканирование UDA полей не только из файла, а из Иерархий тоже, получать весть список UDA полей и выводить их в DataGrid для каждой иерархии.
С уважением.
 

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

7. Можно добавить дополнительную кнопку "Создать иерархию", которая создавала бы определение иерархии и соответствующую ей корневую категорию.

10. Согласен, что разные иерархии должны иметь разный набор атрибутов. Нужно сделать это через настройки. Если оставаться с yaml-файлом, то в секции categories должна быть своя подсекция category_udas.



#9 Artem Terekhov (152852)

Artem Terekhov (152852)

    New Member

  • Members
  • Tekla Maintenance Users, Tekla UFP Users
  • 20 posts

Posted 15 November 2021 - 07:02 AM

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

7. Можно добавить дополнительную кнопку "Создать иерархию", которая создавала бы определение иерархии и соответствующую ей корневую категорию.

10. Согласен, что разные иерархии должны иметь разный набор атрибутов. Нужно сделать это через настройки. Если оставаться с yaml-файлом, то в секции categories должна быть своя подсекция category_udas.

3. Хорошо, логика в API позволяет каждой иерархии иметь детей и объекты, не зависящие от объектов детей. Если проводить аналогию с папками, то каждая папка может иметь внутри другие папки, но при этом может иметь и файлы, которые не находятся в папках, это "честно", но при этом сама папка должна иметь возможность считать все файлы, которые лежат в ней и в папках в ней тоже, также она должна уметь выделять все "файлы" в том числе и вложенные внутри в другие папки, справедливо? :-k 
7. Данная кнопка нужна только если файл yaml "поделится" возможностью создавать корневые иерархии, можно попробовать, сделать сортировку Иерархий, не относящихся к Данному Классификатору через проверку Определения и его типа, то есть что бы приложение создавала Определение типа Custom и полем Type = "Russia" и составляла список только из Объектов, у которых назначено данное определение. Определение нужно создавать только после первого запуска приложения.
10. Возможно, будет удобным выделить общие UDA пола (Которые имеют все Иерархии по умолчанию), но и иметь возможность назначать уникальные для корневых Иерархий.



#10 Artem Terekhov (152852)

Artem Terekhov (152852)

    New Member

  • Members
  • Tekla Maintenance Users, Tekla UFP Users
  • 20 posts

Posted 22 November 2021 - 05:18 AM

Здравствуйте, коллеги.
Что поменялось в версии Hierarchy Manager 0.3?



#11 Igor Erokhin

Igor Erokhin

    Active Member

  • Moderators
  • Tekla Maintenance Users, Tedds Maintenance Users, Structural Designer Maint. Users, Tekla UFP Users, Tekla EPM Maintenance Users
  • 167 posts

Posted 22 November 2021 - 07:01 AM

Здравствуйте, коллеги.
Что поменялось в версии Hierarchy Manager 0.3?

Добрый день, Артем.

 

В версии 0.3 мы исправили ошибки.

Изменения в версиях можно смотреть в файле ReleaseNotes.txt в папке установки дополнения. Также этот файл мы выкладываем на вкладке Release notes/Замечания к выпуску на странице дополнения в Warehouse.

 

P.S. В ближайшее время я напишу наши предложения по дальнейшему развитию дополнения.



#12 Igor Erokhin

Igor Erokhin

    Active Member

  • Moderators
  • Tekla Maintenance Users, Tedds Maintenance Users, Structural Designer Maint. Users, Tekla UFP Users, Tekla EPM Maintenance Users
  • 167 posts

Posted 22 November 2021 - 01:19 PM

Вырисовывается такой roadmap:

  1. Нужно немного изменить концепцию, отказаться от принципа "одно определение иерархии = одно дерево". Нужно иметь возможность выбирать определение иерархии для категории. Это нужно для того, чтобы иметь разный набор пользовательских атрибутов для разных типов категорий. В настройках (или конфиг-файле) нужно реализовать соответствие определениям иерархий списка пользовательских атрибутов для них.

    Более того, нужно реализовать возможность создавать иерархию определений иерархий, для того, чтобы можно было наследовать списки атрибутов от родительских определений иерархий к дочерним. (Например, атрибут Description нужен для всех категорий, поэтому он будет в определении иерархии General, и будет наследоваться всеми дочерними, более специфическими определениями иерархий со своим дополнительным списком атрибутов.)

    В эту концепцию можно вписать опции "разрешать/запрещать уникальность объектов модели в поддереве" и "разрешать/запрещать добавление объектов модели в категорию, которая содержит дочерние категории". Если есть соответствующие атрибуты (назначенные с помощью определения иерархии), то всё поддерево от текущей категории будет работать по соответствующим правилам. (Складывать или не складывать количество объектов в поддереве для родительской категории, будет зависеть от этого атрибута: если запрещать добавление - то складывать, если разрешать - то выводить два числа: количество объектов в родительской категории и сумма объектов в его подкатегориях.)
  2. Нужно сделать отображение всех категорий из базы данных модели, для того, чтобы ничего не терялось, и не было лишнего непонимания. В будущем реализовать возможность фильтрации в интерфейсе программы.
  3. Все-таки я думаю, что суперкорневая категория не нужна. Скорее, нужно сделать возможность создавать категории в корне. Например, если ничего не выбрано, то создаем не дочернюю категорию, а категорию в корне (либо, через кнопку "Создать категорию в корне").
  4. Нужны стандартные иерархии в виде экспортированного файла или в шаблоне модели. Начнем с категорий спецификации металлопроката, потом сделаем стандартные категории в соответствии с методикой КСИ.
  5. Также нужны стандартные определения иерархий (выше уже писал про определение иерархии General с атрибутом Description). Также нужны определения иерархий, соответствующие аспектам и другим сущностям из КСИ.
  6. Добавить возможность задавать имя и путь файла при экспорте и импорте иерархий.
  7. Настройки приложения перенести в интерфейс программы (в том числе нужен редактор иерархий определений иерархий).
  8. Вынести идентификатор категории в диалоговое окно, сделать копируемым.
  9. В диалоговое окно добавить список объектов модели для выбранный категории. Выбирать и зумировать объекты при выборе конкретной строки из списка.
  10. Убрать кнопку "Применить".
  11. Не делать поля UDA категорий, у которых есть дети, нередактируемыми.
  12. Контекстное меню для категорий с наиболее релевантными командами.
  13. Drag’n’drop для копирования и перемещения категорий от одного родителя к другому.
  14. Добавить флажок "включая подкатегории" рядом с флажком "Выбирать объекты модели".
  15. Сортировка подкатегорий внутри родительской категории (пользовательская при создании, по алфавиту и обратно).
  16. Сделать отчеты, отображающие принадлежность объекта модели категории (проверить, возможно ли это).
  17. Загрузка дерева по мере раскрытия узлов (lazy load).
  18. Асинхронность там, где это возможно.




Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users