Структура проекта
HoneyPlatfrom позволяет жить как в микросервисной инфраструктуре, так и в монолитных решениях. В том числе все узлы проекта могут быть запущены на одной локальной машине разработчика.
Проект можно разбить на несколько логических частей.
Каждая часть, кроме файла проекта, может иметь несколько веток в репозиториях или в локальных папках. Подробнее об этом в разделе Deployment.
1. Файл проекта
Файл проекта содержит информацию о проекте, о ветках (Branch), контурах (Environment).
При разработке на облачном Dev-сервере вместо физического файла может быть использована БД, также может быть добавлена информация о доступах отдельных пользователей к тем или иным частям проекта. Однако всю информацию, поддерживаемую локально, можно выгрузить в файл.
Локальная разработка
При локальной разработке файл с расширением .honeyproject размещается в файловой системе. При запуске Dev-сервера из IDE необходимо указать ссылку на файл в переменной окружения buildServerDefaultLocalPath (при этом переменная buildServerUseDefaultLocalPath должна быть равна true).
Задать переменную окружения, можно, например в launchSettings.json
"buildServerDefaultLocalPath" : "c:\\dev\\example\\example.honeyproject"Формат файла - yaml. (Пофиксить, чтобы реально был yaml)
{
"Name" : "Test project",
"Description" : "The test project in files",
"Settings" : [
{
"Key" : "HomePage.PageName",
"Level" : 2,
"CustomName" : null,
"Value" : "Page1"
}
],
"Exclude" : [
"Models/User2.model"
]
}
Необходимо реализовать и дописать, какие будут поля для хранения контуров и веток
DEV-сервер
При разработке с помощью DEV-сервера рекомендуется использовать UI для редактирования файла проекта.
Сюда нужно будет вставить скриншоты с DEV-портала и кратко описать что есть что.
2. Описание данных и процессов
Все файлы данной части должны располагаться в одной корневой папке на диске или репозитория. При сборке будут учитываться все файлы из корневой папки и её потомков, если в файле проекта явно не указано исключение.
Файлы описания данных
Подробнее про структуру файлов в разделе Данные и источники данных
Краткая таблица файлов
.class
JSON (будет YAML)
Описывает один класс
.link
JSON
Описывает одну именованную связку
.enum
JSON
Описывает пользовательский тип данных типа Enum
.record
JSON
Описывает пользовательский тип данных типа Record
.datasource
JSON
Описывает источник данных
Файлы описания процессов
Подробнее про структуру файлов в разделе Процессы и комбы
Краткая таблица файлов
.process
YAML
Описывает один процесс
.filters
YAML
Описывает соотношение комбов (фильтров) и нод, на которых они могут быть исполнены
Файлы ресурсов
Файл с расширением .resource описывают ресурсы системы - файлы, которые будут доступны в неизменном виде.
Формат файла JSON (возможно, будет YAML), описывает перечень ресурсов
{
"ResourceGroupName": "TaskAgentData",
"Resources": [
{
"Name": "task_agent_data",
"File": "task_agent_data.json",
"ResourceType": 5
}
]
}В дальшейшем будет добавлен пример селекторов и в каком-нибудь разделе всё будет подробно рассмотренно.
Ресурсы ссылаются на файлы, путь к которым должен быть задан относительно пути .resource файла.
Поле ResourceType должно быть заменено и должны быть перечислены все его варианты (если оно не будет упразднено).
Справочники
Файлы справочников - файлы с расширение .refs - описывают статические справочник в табличном виде.
Формат файла на данный момент JSON, требуемая структура:
Name - называние справочника
Columns - список столбцов таблицы
KeyColumn - список столбцов, являющихся ключами. По ключу записи будут доступны значение всех остальных столбцов для данной записи
Values - список массивов, содержащих значения. Размер каждого массива должен совпадать с количеством столбцов таблицы
Пример файла
{
"Name": "ApplicationDocumentTypeLanguageSet",
"Columns": [
"key",
"en",
"ru"
],
"KeyColumns": [
"key"
],
"Values": [
[
"application-document-type.2ndfl",
"2-NDFL",
"2-НДФЛ"
]
]
}
В будущем планируется ввести некоторый синтаксис для работы с селекторами
Модели
В данный момент решается, должны ли модели находиться в этой части проекта или во фронтэнде. Также остатся не до конца ясной область применения моделей, в виду появления новых комбов (фильтров) для выполнения сложных запросов
Файл модели - файл с расширением .model - используется для сборки данных по объектам из различных классов в одну модель. Формат файла - yaml.
Поля:
name - уникальное для проекта имя модели
properties - список всех свойств модели, каждое свойство описывается:
name - имя свойства
type - тип данных у данного свойства. Допустимые типы:
Стандартные: string, long, decimal, datetime, date
json - объект любой структуры
single - объект указанной в параметрах модели
array - массив объектов указанной в параметрах модели
Пользовательский тип enum или record, значение указывается с символом @ в начале
out - правило для преобразования входящих значений в значение модели. Подробнее где-то по ссылке
3. Часть Application (Frontend Application)
Часть Application описывает взаимодействие с Frontend-приложением и содержит код приложения.
Данных частей может быть несколько.
Файл .app
(Пока не реализовано) Файл описывает Frontend приложение. Формат JSON.
Содержит:
Name - имя приложения, обязательно поле
Path - массив с путями, где находятся файлы приложения. По умолчанию содержит единственное значение "**", означающее, что нужно смотреть папке, где находится .app файл и во всех дочерних
Exclude - массив с путями для исключения папки или файла
Import - массив с модулями из других приложений, которые будут импортированы в текущее
Пример файла
{
"Name": "corporative-portal",
"Path" : [
"**"
],
"Exclude" : [],
"Import" : [
{
"App" : "common-app",
"Modules" : [
"auth",
"windows"
]
}
]
}На приложение (по имени) должна ссылаться нода типа HostServer, тогда оно будет загружаться по адресу ноды.
Если на приложение ничего не ссылается - оно загружаться не будет, однако такие приложения можно использовать в качестве библиотек модулей.
Файлы модулей
Файлы модулей - с расширением .module - описывают модули приложений. Формат файлов - JSON, структура похожа на .app. Содержит:
Name - имя модуля
AutoLoad - указывает, должен ли модуль быть автоматически загружен в приложение или загрузка будет по требованию
Path - массив с путями, где находятся файлы модуля.
Exclude - массив с путями для исключения папки или файла
По путям, указанным в Path, в модуль будут включены все файлы. Ко всем этим файлам будет доступ со стороны клиента, поэтому не следует помещать туда файлы, содержимое которых стоит скрыть. Также не следует помещать туда слишком большие файлы - это может привести к снижению производительности и увеличению времени загрузки. Для обоих случаев стоит использолвать ресурсы.
Представления
Файл представления - с расширением .view - описывают одно представление.
Формат файла - JSON, структура:
Name - имя представления
Description - описание, может быть пустым
Module - имя модуля, к которому относится представление
Пример:
{
"Name": "SystemMenuIndex",
"Description": "Описание данного представления",
"Module": "menu"
}
Стоит учитывать, что данные о представлении будут известны вне зависимости от того, был загружен указанный модуль или нет. Однако, если при открытии представлений модуль ещё не был загружен, то произойдёт инициация его загрузки.
Файлы Page
Файлы с расширением .page, описывают страницу в приложении. Используются, когда необходимо задать Input для загрузки представления. В данный момент судьба этих файлов не ясна, возможно будут исключены из платформы.
Формат файла - JSON, структура:
Name - имя страницы
Description - описание, может быть пустым
ViewName - имя представления
Input - произвольный объект, значение которого помещается в Input
Файлы запросов
Файлы запросов - файлы с расширением .request - описывают запросы со стороны Frontend-приложения к серверной части. Пока под вопросов, в какой части они должны находиться, тут или в описании данных и процессов.
Формат - JSON, структура:
Name - имя запроса
ResponseMethod - стратегия получения ответа на запрос:
Immediate - ответ ожидается сразу, если вернётся ответ с необходимостью ожидания, будет сгенерировано исключение.
Default - решение, выдавать ли ответ сразу, принимает сервер.
Delay - ожидается отложенный ответ. Если ответ вернётся сразу, исключение сгенерировано не будет, будет вызван переданный callback
ProcessName - имя процесса
EndpointNumber - номер точки входа в процесс (Endpoint)
OutputNumber - номер комба типа Output для получения результата
Url - не понятно, зачем это, уточнить
Last updated