logologo
Начало
Руководство
Разработка
Плагины
API
Главная
English
简体中文
日本語
한국어
Español
Português
Deutsch
Français
Русский
Italiano
Türkçe
Українська
Tiếng Việt
Bahasa Indonesia
ไทย
Polski
Nederlands
Čeština
العربية
עברית
हिन्दी
Svenska
Начало
Руководство
Разработка
Плагины
API
Главная
logologo

Введение

Что такое FlowEngine?
Связь FlowEngine и плагинов
Быстрый старт
План обучения

Руководство

Регистрация FlowModel
Создание FlowModel
Рендеринг FlowModel
Поток событий и конфигурация FlowModel
Персистентность FlowModel
Жизненный цикл FlowModel
Система контекста FlowModel
Реактивный механизм: Observable
FlowModel vs React.Component
Точки расширения плагина RunJS

Определения

ModelDefinition
FlowDefinition
EventDefinition
ActionDefinition
StepDefinition
Previous PageЖизненный цикл FlowModel
Next PageРеактивный механизм: Observable
Уведомление об ИИ-переводе

Этот документ был переведён с помощью ИИ. Для получения точной информации обратитесь к английской версии.

#Обзор системы контекстов

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

  • FlowEngineContext (глобальный контекст): Глобально уникален, доступен для всех моделей и рабочих процессов, подходит для регистрации глобальных сервисов, конфигураций и т. д.
  • FlowModelContext (контекст модели): Используется для совместного использования контекста внутри дерева моделей, дочерние модели автоматически делегируют контекст родительской модели, поддерживает переопределение имен, подходит для изоляции логики и данных на уровне модели.
  • FlowRuntimeContext (контекст выполнения рабочего процесса): Создается при каждом выполнении рабочего процесса, проходит через весь цикл выполнения, подходит для передачи данных, хранения переменных, записи состояния выполнения и т. д. Поддерживает два режима mode: 'runtime' | 'settings', соответствующих состоянию выполнения и состоянию настройки.

Все FlowEngineContext (глобальный контекст), FlowModelContext (контекст модели), FlowRuntimeContext (контекст выполнения рабочего процесса) и т. д. являются подклассами или экземплярами FlowContext.


#🗂️ Схема иерархии

FlowEngineContext (глобальный контекст)
│
├── FlowModelContext (контекст модели)
│     ├── Дочерний FlowModelContext (дочерняя модель)
│     │     ├── FlowRuntimeContext (контекст выполнения рабочего процесса)
│     │     └── FlowRuntimeContext (контекст выполнения рабочего процесса)
│     └── FlowRuntimeContext (контекст выполнения рабочего процесса)
│
├── FlowModelContext (контекст модели)
│     └── FlowRuntimeContext (контекст выполнения рабочего процесса)
│
└── FlowModelContext (контекст модели)
      ├── Дочерний FlowModelContext (дочерняя модель)
      │     └── FlowRuntimeContext (контекст выполнения рабочего процесса)
      └── FlowRuntimeContext (контекст выполнения рабочего процесса)
  • FlowModelContext через механизм делегирования (delegate) может обращаться к свойствам и методам FlowEngineContext, реализуя совместное использование глобальных возможностей.
  • FlowModelContext дочерней модели через механизм делегирования (delegate) может обращаться к контексту родительской модели (синхронная связь), поддерживает переопределение имен.
  • Асинхронные родительские и дочерние модели не устанавливают отношения делегирования (delegate), чтобы избежать загрязнения состояния.
  • FlowRuntimeContext всегда обращается к соответствующему FlowModelContext через механизм делегирования (delegate), но не передает данные обратно вверх.

#🧭 Состояние выполнения и состояние настройки (mode)

FlowRuntimeContext поддерживает два режима, которые различаются параметром mode:

  • mode: 'runtime' (состояние выполнения): Используется на этапе фактического выполнения рабочего процесса, свойства и методы возвращают реальные данные. Например:

    console.log(runtimeCtx.steps.step1.result); // 42
  • mode: 'settings' (состояние настройки): Используется на этапе проектирования и настройки рабочего процесса, доступ к свойствам возвращает строку шаблона переменной, что удобно для выбора выражений и переменных. Например:

    console.log(settingsCtx.steps.step1.result); // '{{ ctx.steps.step1.result }}'

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


#🤖 Контекстная информация для инструментов / больших языковых моделей

В определенных сценариях (например, редактирование кода RunJS в JS*Model, AI-кодинг) необходимо, чтобы «вызывающая сторона» понимала следующее без выполнения кода:

  • Какие статические возможности есть в текущем ctx (документация API, параметры, примеры, ссылки на документацию и т. д.).
  • Какие доступные переменные есть в текущем интерфейсе/состоянии выполнения (например, динамические структуры, такие как «текущая запись», «запись текущего всплывающего окна» и т. д.).
  • Компактный снимок текущей среды выполнения (для prompt).

#1) await ctx.getApiInfos(options?) (статическая информация API)

#2) await ctx.getVarInfos(options?) (информация о структуре переменных)

  • Построение структуры переменных на основе defineProperty(...).meta (включая meta factory).
  • Поддержка обрезки path и контроля глубины maxDepth.
  • Развертывание вниз только при необходимости.

Часто используемые параметры:

  • maxDepth: максимальный уровень развертывания (по умолчанию 3).
  • path: string | string[]: обрезка, вывод только поддерева по указанному пути.

#3) await ctx.getEnvInfos() (снимок среды выполнения)

Структура узла (упрощенная):

type EnvNode = {
  description?: string;
  getVar?: string; // Можно использовать напрямую для await ctx.getVar(getVar), начинается с "ctx."
  value?: any; // Разрешенное/сериализуемое статическое значение
  properties?: Record<string, EnvNode>;
};