The easiest way of working (for our users) imho would be that you store the json tree in the flow.json file, as a config node property. Because the eveything works out of the box, like they are used to do.
However, whether or not you can store the json tree in the config node seems to me dependent on how we need to update that static config that is not related to ui nodes (i.e. position of the widgets, and then the config of panels, grids, tabs, ...):
If you need to use an isolated external layout manager, then you need the update the flow via the server side. I have not done that yet, but I assume that is what Nick means with the admin http api above?
If you can somehow integrate a layout manager into the config node's config screen, then a user can use that to change the config node properties. Once done, he can deploy the flow (and the config node changes), and from here on it all works out of the box automatically.
For me option 2 would be the most user friendly, but completely no idea whether something like that is possible.
The layout is a grid (like the current dashboard), so each widget has a width and height in grid units, just like in the current dashboard.
Yes, that's correct. But for export/import to work correctly I have to do the same thing the dashboard currently does, which is to have fd-panel, fd-grid, and fd-tab config nodes (equiv to the ui_group and ui_tab config nodes. To do that I have to invert my data structure: right now a grid has an array of widget IDs, and instead each widget will need to have the ID of the grid that contains it, and like that up the tree. Not the end of the world, but more than JSON.dump...
Right now I'm not a fan of that idea anymore. I'd like to spend my effort on improving the live layout editing in the dashboard directly. That's such a better experience. The result can be stored in the flow. All I need to do to fit the NR model is to keep such edits in memory until the user clicks on a 'save layout' button, or perhaps I can hook into the deploy button...
