Matti Airas - Upcoming changes to SensESP: Refa...

Upcoming changes to SensESP: Refactoring of how web UI configuration cards are defined in the C++ code. So far, any class inheriting from

Configurable

Configurable

Configurable

Configurable and having a config path defined would expose a REST API endpoint for GETting and PUTting its configuration, and if it has a config schema defined, a config card would also be rendered in the UI.

This approach has the problem that the configuration UI definition is tightly tied to the object, breaking the single responsibility principle and making some things more messy than necessary. I made a PR for refactoring this: now, all config items need to be defined explicitly by calling

ConfigItem(obj)

ConfigItem(obj)

ConfigItem(obj)

ConfigItem(obj). The returned pointer can be used to chain other settings together:

  // Create a frequency transform
  auto* frequency = new Frequency(1, "/Transforms/Frequency");

  ConfigItem(frequency)
    ->set_title("Engine RPM")
    ->set_description("Engine revolutions (Hz)")
    ->set_sort_order(1100);

  // Create a frequency transform
  auto* frequency = new Frequency(1, "/Transforms/Frequency");

  ConfigItem(frequency)
    ->set_title("Engine RPM")
    ->set_description("Engine revolutions (Hz)")
    ->set_sort_order(1100);

  // Create a frequency transform
  auto* frequency = new Frequency(1, "/Transforms/Frequency");

  ConfigItem(frequency)
    ->set_title("Engine RPM")
    ->set_description("Engine revolutions (Hz)")
    ->set_sort_order(1100);

  // Create a frequency transform
  auto* frequency = new Frequency(1, "/Transforms/Frequency");

  ConfigItem(frequency)
    ->set_title("Engine RPM")
    ->set_description("Engine revolutions (Hz)")
    ->set_sort_order(1100);

The default config schema (which defines the properties of the web UI interface) can be provided for each class by defining an overloaded

ConfigSchema

ConfigSchema

ConfigSchema

ConfigSchema function:

const String ConfigSchema(const Frequency* obj) {
  return R"###({
    "type": "object",
    "properties": {
        "multiplier": { "title": "Multiplier", "type": "number" }
    }
  })###";
}

const String ConfigSchema(const Frequency* obj) {
  return R"###({
    "type": "object",
    "properties": {
        "multiplier": { "title": "Multiplier", "type": "number" }
    }
  })###";
}

const String ConfigSchema(const Frequency* obj) {
  return R"###({
    "type": "object",
    "properties": {
        "multiplier": { "title": "Multiplier", "type": "number" }
    }
  })###";
}

const String ConfigSchema(const Frequency* obj) {
  return R"###({
    "type": "object",
    "properties": {
        "multiplier": { "title": "Multiplier", "type": "number" }
    }
  })###";
}

A completely custom schema can be also given to the

ConfigItem

ConfigItem

ConfigItem

ConfigItem object if desired.

I realize this is a breaking change but I believe this makes end user code easier to read and follow, and there's hopefully a bit less magic happening in the background.

Here's the PR: https://github.com/SignalK/SensESP/pull/761

GitHub

Refactor web UI config item C++ implementation by mairas · Pull Req...

This is a biggie. Previously, there was a Configurable class that made a config card appear on the web UI whenever something inherited that. However, the implementation made many assumptions on how...

No replies yetBe the first to reply to this messageJoin

Matti Airas - Upcoming changes to SensESP: Refa...

Similar Threads