Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

standardize import / exports with exported info on data type #1285

Open
steersbob opened this issue May 11, 2020 · 0 comments
Open

standardize import / exports with exported info on data type #1285

steersbob opened this issue May 11, 2020 · 0 comments

Comments

@steersbob
Copy link
Member

steersbob commented May 11, 2020

Reasoning

Import/Export dialogs are scattered throughout the UI, and would benefit from centralization.
Import functions rely on the user to provide the correct JSON file, and only do cursory schema verification.

Including type and version metadata in exported files lets us build a centralized one-size-supports-all import dialog.

Architectural vision

We could leave export buttons in specific actions, or build a centralized export overview with a multiselect tree of included items. This is something best evaluated with a proof of concept.

Exported files contain an array of objects. The overhead for single item exports is negligible, and this makes it much more convenient to export entire setups.
When importing, we can display a confirmation multi-select with all objects detected in the file.
Each object includes type and version metadata, to allow for mixed exports.

During exports, all ID properties are replaced with variable placeholders (eg. {{LONG_ID}}, {{SHORT_ID}}, {{SPARK_SERVICE}}, {{DASHBOARD_ID}}). The export function has to be type-aware to handle replacement while keeping references intact, but the import function can scan the entire JSON string, and replace all occurrences with new UIDs.

References to non-random IDs like Spark services and dashboards can be grouped. It can be assumed that if an export contains 5 blocks all belonging to the same service, they should also be imported as 5 blocks on a single service.

When exporting block widgets, it should be suggested to also export the block itself, as the widget has very little configuration.

Types supporting export:

  • widgets
  • blocks
  • layouts
  • system config
  • setpoint profiles
  • sessions

Dashboards and services do not need to be directly exportable.
When importing widgets, the user can choose whether to place them on an existing dashboard, or create a new one.
When importing blocks, the user can only choose from pre-existing services, as services are typically discovered, and not created.

@steersbob steersbob moved this to Accepted in BrewBlox May 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Accepted
Development

No branches or pull requests

1 participant