Method to get all available DynamicModule variables?

[portokallidis]

Currently to get the value of a DynamicModule variable in a notebook, you have to explicitly set the name of the variable.
This is a huge limitation when it comes to deeper integrating the WL Notebooks within 3rd party platforms.

Ideally you can expose a method to discover all the "available" dynamic module variables in the embedded notebook which in turn will allow the creation of notebook agnostic functionalities such as "save and resume"**

**By exporting the current internal state of a Notebook (using getDynamicModuleVariable) and re-importing it (using setDynamicModuleVariable) at a later point in time to introduce advanced "save and resume" capabilities, especially in somewhat larger notebooks with multiple cells.

[jfultz]

Take a look at the documentation for TaggingRules which includes examples of using TaggingRules to emulate DynamicModule-type functionality, but which can be scoped to the notebook as a whole. I think this is the sort of thing you're looking for, and Wolfram frequently uses this technique in developing its own interfaces. Also, TaggingRules at the notebook level in a palette will automatically be stored in your front end preferences. Discussion of this can be found in the Storing and Tracking Palette States Tech Note.

I'm speaking here of things which are fully implemented in the desktop FE...some of it (particularly the palettes) is less relevant at the Cloud level, although I believe that Cloud does have an understanding of TaggingRules, et. al at the notebook level.

[portokallidis]

@jfultz Thank you for the reference, I guess the "save and resume" can be achieved by TaggingRules in Desktop FE.
But I am referring to the scope of this library (Notebook-Embedder) which promises seamless integration with the web platform (html-css-js).
Looking at this from the perspective of a 3rd party WEB platform,
saving and loading state is already possible using the existing methods:

• setDynamicModuleVariable
• getDynamicModuleVariable

But my point is that its very limited because it can only be used with predefined variables.
On the other hand, by exposing only one method to "discover" all the available variables in the notebook like:

• getAllDynamicModuleVariables

will make this a powerful and generic approach for storing/loading state on any cloud notebook.
I know that this may not be as simple as it sounds so for now its only food for thought.

[kubaPod]

@portokallidis just to make it clear.

A notebook contains many cells. Each cell can contain many dynamic modules. There's more, dynamic modules can be nested.

Currently if you have cell's ID you can use the API to operate on the first dynamic module found in that cell.

So even with getAllDynamicModuleVariables you still need setALLDynamicModuleVariables because currently you can only us this for the first dynamic module in each cell.

This boils down to a request for a more fine grained control, including selecting them, over dynamic module instances.

@jfultz @poeschko for what's it worth, our case involves single cell with a one case of a nested modules:

DynamicModule[{ specControlledByUs },
  ...
  Manipulate[
    ...
  , externalSpec (* we parse it to get variables list *)
  , injectedDynamicWrapperThatManagesCommunicationBetweenSpecs
  ]
]

As for save and resume feature there are alternatives as making copy of notebooks or making notebooks only as a result of API[{DMstate}, action. Or even Delayed notebooks. But that is very case sensitive and diverges from the OP.