Процесс разработки конфигуратора с json-editor

From Wiren Board
This is the approved revision of this page, as well as being the most recent.


Список страниц по JSON-editor

  1. Введение в веб-конфигурирование wb-rules с помощью JSON-editor
  2. Процесс разработки конфигуратора с JSON-editor
  3. Описание работы с JSON-editor

Описание

Страница описывает логику взаимодействия элементов конфигуратора между собой и процесс разработки конфигуратора с использованием json-editor.

Используемые сущности

Опишем файлы которые нужно создать на контроллере - они будут взаимодействовать между собой в процессе работы решения:

1. Файл схемы

В файле схемы описывается WEBUI (пользовательский интерфейс), который будет генерироваться с использованием json-editor.

Расположение файлов схем:

/usr/share/wb-mqtt-confed/schemas/*.schema.json

2. Конфиг JSON

В конфиг JSON сохраняются настройки заданные пользователем в веб-интерфейсе.

Расположение файлов конфигов JSON:

/etc/*.conf

3. Файл пользовательского сценария wb-rules

Файл правил wb-rules виден пользователю, если расположен каталоге:

/etc/wb-rules/rules.js

Файл сценария wb-rules:

  1. Проверяет конфиг на наличие включенного состояния.
  2. Если конфиг включен — инициализирует его, создавая виртуальное устройство, и включает методом enable.
  3. При выключении устройства либо уничтожает его (тогда пропадут виджеты), либо отключает (тогда созданные виджеты останутся).

4. Файл модуля

Опционально может быть еще файл модуля. Модули не видны пользователям через веб-интерфейс.

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

Модули могут быть расположены в каталогах:

/etc/wb-rules-modules 
/usr/share/wb-rules-modules

Подробнее про написание модулей можно прочесть тут https://github.com/wirenboard/wb-rules?tab=readme-ov-file#модули

Логика работы решения

В процессе работы решения происходят следующие взаимодействия:

  1. Разработчик указывает в файле схемы какой сервис перезагружается.
    В нашем случае это сервис wb-rules, но может быть любой сервис. Это делается, чтобы ускорить чтение нового конфигурационного файла, так как в линукс, в простом случае, сервисы читают свои конфиги именно при запуске.
  2. Пользователь в WEBUI заходит в конфигуратор, заполняет поля настроек и нажимает Записать.
  3. После записи настроек происходит два действия:
    • сначала данные из формы записываются в ваш конфиг файл /etc/*.conf;
    • далее перезапускается сервис который вы указали на шаге 1, в нашем случае wb-rules.
  4. При перезапуске сервиса в linux происходит чтение нового конфига.
    В нашем случае при перезапуске сервиса wb-rules должны произойти следующие действия:
    • при старте сервис wb-rules запустит выполнение каждого скрипта js для wb-rules;
    • в вашем скрипте wb-rules конфиг файл прочтется функцией readConfig();
    • скрипт выполнится с использованием данных, полученных из прочитанного файла конфигурации.

Таким образом, данные, введенные пользователем в WEBUI, можно использовать в скрипте wb-rules.

Процесс разработки

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

  1. Анализ функциональности:
    • что должен делать скрипт wb-rules;
    • какие параметры будут заданы пользователем, а какие будут неизменяемыми;
    • какой внешний вид будут иметь настраиваемые параметры на странице WEBUI;
    • какие значения по умолчанию должны быть у параметров.
  2. Создание файла JSON схемы для описания формы в WEBUI:
    • создание файла схемы и его заполнение;
    • создание файла конфига с пустой структурой для вашего конфигуратора;
    • тестирование файла схемы и конфига на совместную работу. Проверка, что конфигуратор открылся в браузере без ошибок и в него записались данные из WEBUI.
  3. Создание JSON-конфиг файла вручную.
    В первый раз нужно создать файл конфига вручную, далее с его помощью мы сможем запустить ранее описанный конфигуратор и сможем изменять конфиг через WEBUI.
  4. Проверка корректности запуска конфига в WEBUI.
    На данном этапе важно добиться чтобы:
    • мы увидели новую добавленную конфигурацию на странице "Конфигурационные файлы";
    • после нажатия на конфиг мы увидели в браузере форму описанную JSON-схемой;
    • все поля, описания полей и другие элементы отображались корректно;
    • проверки регулярных выражений, минимальных длин и др. должны отрабатываться корректно и не сохранять конфиг при ошибке;
    • после настройки параметров мы должны иметь возможность их сохранить;
    • сохраненные настройки должны корректно записаться в файл конфига.
  5. Сохраняем конфиг с несколькими настроенными объектами.
    Данный шаг дает нам конкретную структуру файла с которой можно работать из скриптов.
  6. Создание файла скрипта wb-rules.
    Данный файл должен содержать следующую функциональность:
    • чтение конфигурационного файла;
    • логику работы самого скрипта;
    • логи начала выполнения и ошибок - чтобы по логу можно было понять что запускалось и какие ошибки происходили.
  7. Тестирование совместной работы конфига и нашего скрипта.
    Есть два варианта изменения файла конфига:
    • ручное изменение файла конфига в текстовом редакторе и перезапуск wb-rules в консоли. Перезапуск через консоль полезен при отладке и когда есть сервис, который записывает данные в конфиг в автоматическом режиме;
    • изменение файла конфига через WEBUI, тогда wb-rules будет перезапускаться автоматически.
  8. Наблюдение за процессом работы скрипта в логах.
    Для этого до записи настроек активируйте панель логов в браузере нажав на кнопку с гаечным ключом внизу справа.
  9. Результат.
    У вас будет скрипт wb-rules, который берет настройки, указанные пользователем, в WEBUI и применяет их для работы определенного правила wb-rules, тем самым меняя поведение при работе скрипта.

Статьи по теме


Навигация

← Назад: Введение в WEB-конфигурирование wb-rules с помощью JSON-editor
Страница (2 из 7): Процесс разработки конфигуратора с JSON-editor
Вперед →: Пример разработки конфигуратора с JSON-editor