Opened 7 years ago
Closed 7 years ago
#1661 closed enhancement (fixed)
Support adding state managers from bundles
| Reported by: | Conrad Huang | Owned by: | Conrad Huang |
|---|---|---|---|
| Priority: | major | Milestone: | 0.9 |
| Component: | Tool Shed | Version: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Notify when closed: | Platform: | all | |
| Project: | ChimeraX |
Description
Session state managers are useful mechanisms that provide a centralized resource (found via the session) for both managing features (e.g., presets) and for saving state in sessions. Currently, most state managers are initialized by the core (the alignment state manager is initialized from a bundle via custom_init). It would be nice to formalize the process for using bundles to implement state managers and their managed resources because it would help (a) limit number of changes to the core, and (b) allow more frequent updates via the toolshed.
The proposed changes are:
- Add
<Manager>and<Providers>tag tobundle_info.xmlschema. These tags translate to ChimeraX classifiers in the generatedsetup.pyfile and will ultimately end up as metadata for the toolshed to read. - Modify the toolshed to track "generic" state managers and providers in bundles and to initialize managers "at the appropriate time."
- The
BundleAPI will need at least two new method:manager_init(for initializing a state manager) andprovider_run(for invoking a particular provider, which may be lazily registered to delay importing a bundle package). Other potential methods that may be added as needed includemanager_resetandprovider_init. - The
manager_initmethod is called with the state name (e.g., "presets") to create the state manager instance, which is expected to query to toolshed for providers with the same name. The state manager instance is returned so that the toolshed can register the state manager in the session. - The toolshed will treat bundles that define
manager_initsimilarly to those that definecustom_init. The bundle package will be imported and the methods called after all bundles have been read in (this is "the appropriate time" for now, although it may be possible to support init-on-demand later). This order is needed to guarantee that the toolshed "knows" all the providers for a state manager before trying to create the state manager.custom_initwill be called first, followed bymanager_init. - Toolshed needs to support run-time ordering of bundles to make sure that "provider" bundles with
custom_initmethods are called after their state manager has been created. This will require adding another tag tobundle_info.xml. - Before "provider" or "manager" bundles are unloaded, methods should be called to notify affected state manager instances. When "manager" bundles are installed, the state manager instances should be created. When "provider" bundles are installed, their state manager instances should be notified.
- The
Change History (5)
comment:1 by , 7 years ago
| Blocking: | → 1720 |
|---|
comment:2 by , 7 years ago
| Blocking: | 1720 |
|---|
comment:3 by , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:4 by , 7 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Implementation was incorrect because it always initialized providers instead of lazily running them as they are invoked. To delay import, presets_mgr will need to be changed to collect provider information differently.
comment:5 by , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
New API implemented and committed 040c391a4.
Implemented in 895143f2c45.
Added Managers, Manager, Providers, Provider, Initializations, InitAfter tags to bundle_info.xml. Added init_manager and init_provider methods to BundleAPI.
Initialization order is: managers, providers, custom.