Skip to main content

Общая информация

Для лучшего понимания раздела "Nodes fiedname" стоит изучить эндпоинты разделов "Step" и "Nodes".

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

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

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

Текущий флоу​

В текущем флоу метод POST /bpm/editor/nodes имеет возможность создавать новую сущность "nodes_fieldname" без сопутствующих настроек вместе с нодой любого типа (нода типа "process" сама по себе не создается с полем "nodeFieldname", тем не менее новая сущность "nodes_fieldname" все равно создается в базе). Эта возможность не является правильным алгоритмом действий, это временная мера обусловленная технической необходимостью.

То есть сейчас, при создании ноды типа "field" ("nodeType": 3):

  • Значение, что введено в поле "name", отображается как тип этого поля под ключом "nodeType". Например: {"name": "input.dropDownList"} -> {"nodeType": "input.dropDownList"}. Это не баг, это техническая необходимость.
  • Поле "title" отсутствует.
  • Значение, что введено в поле "nodeFieldname", отображается как имя этого поля под ключом "name". Например: {"nodeFieldname": "qa.field.test.correct21"} -> {"name": "qa.field.test.correct21"}. Это не баг, это техническая необходимость.
  • Одновременно с нодой типа "field" ("nodeType": 3), создается сущность "nodes_fieldname" без дополнительных параметров.
  • Есть функционал, который может автоматически генерировать значение для "nodeFieldname", генерируя строку из остальных параметров путем конкатенации, но в данное время функционал отключен и не используется.

Будущий флоу​

В будущем флоу метод POST /bpm/editor/nodes не сможет создавать новую сущность "nodes_fieldname" самостоятельно. Более того иметь связь с этой сущностью смогут только те типы нод, которые могут принимать внешние данные пользователей с экранов клиентских приложений для сохранения и обработки. В большинстве случаев, это ноды типа "Поле". У всех остальных типов нод, поля "nodeFieldname" не будет. Например, при создании ноды-поля типа "input", которая смогла бы принимать и сохранять введенные данные какого-то пользователя будет следующая ситуация:

  • Значение, что введено в поле "name", отображается как тип этого поля под ключом "nodeType". Например: {"name": "input.dropDownList"} -> {"nodeType": "input.dropDownList"}. Это не баг, это техническая необходимость. Приложение в свою очередь будет уметь различать поля разных типов (Text, TextInput, TextView, DropDown и т.д.) и по разному их обрабатывать.
  • Поле "title" будет также отсутствовать.
  • Поле "nodeFieldname" будет принимать только ID сущности "nodes_fieldname", которая должна быть предварительно создана с помощью метода POST /bpm/editor/nodes/fieldName, где помимо имени "переменной", есть ряд других параметров.

https://dsaturday.notion.site/763b625ed4084319ad05e9fa597fb480

https://dsaturday.notion.site/10bef742945849398a90363b5cd4fae1