Extension Manager - Extension state

[tdipisa]

The extensions need to be managed across three different states:

• Installed: the source code is installed but not available for a viewer
• Loaded: the installed extension is available inside the viewer and ready to be activated
• Activated: the extension is active inside the viewer and ready to be used by the final user

Current context should be saved like this:

{
plugins: {
   desktop: [...] // all the plugins not selectable by the user, already implemented
}
},
userPlugins: // list of plugins that can be enabled by the user [ 
{
   "name": "BackgroundSelector", 
   "active": true // this inidcates that the plugin should be added on startup or not
}, ...
templates: [{id: 1, /* other options of the template */}, {id: 2}] // list of available template

NOTE: active is not present in the mock-up. We should add a checkbox in the UI, when the plugin is checked as user plugin.
Original functionality in mapsfish allows to enable by default some of them before the user selects, so this have to be ported in mapstore

[offtherailz]

This is a RFC of the configuration with the information needed to the plugin configurator.

This should be generated on/by the server OR as a mesh of response from the server and local configuration of plugin configurator.
This

I suggest the first to simplify the work on the client.

The configuration has this shape:

{
 "plugins": [
    { 
        "name": "Map",
        "mandatory": true, // <-- mandatory should not be shown in editor OR not movable and direcly added to the right list. 
    }, { 
        "name": "Notifications",
        "mandatory": true, // <-- mandatory should not be shown in editor OR not movable and direcly added to the right list. 
              "hidden": true, // some plugins are only support, so maybe showing them in the UI is superfluous. 
    }, {
        "name": "TOC",
       "symbol": "layers",  
        "title": "plugins.TOC.title",
        "description": "plugins.TOC.description",
        "defaultConfig": {},
        "children": ["TOCItemSettings", "FeatureEditor"]
    }, {
        "name": "FeatureEditor",
        "defaultConfig":  {}
    }, {
        "name": "TOCItemSettings",
        "...": "..."
    }, {
        "name": "MyPlugin" // <-- this is typically an extension
    }, { 
       "name": "Footer", 
       "children": ["MousePosition", "CRSSelector",  "ScaleBox"]
    }, {
       "name": "Widgets", 
      "children": ["WidgetsBuilderPlugin", "WidgetsTrayPlugin"],
      "dependencies": ["WidgetsBuilderPlugin"], // some plugins may be mandatory only if parent is added.
    }, {
      "name": "WidgetsTrayPlugin"
    },  {
      "name": "WidgetsBuilderPlugin",
      "hidden": true // <-- This is a child. In this case it will be added automatically, without showing 
if the parent is added
}]
}

Properties of plugin entry:
Base Properties:

• name: {string} the name (ID) of the plugin
• title: {string} the title string OR messageId (from localization file)
• description: {string}: the description string OR messageId (from localization file)
• symbol: {string}`: icon (or image) symbol for the plugin
• defaultConfig {object}: optional object containing the default configuration to pass to the context-creator.
• mandatory {boolean}: if true, the plugin must be added to the map, so not possible to remove (but can be customized)
• hidden {boolean}: if true, the plugin should not be shown in UI. If mandatory, is added without showing.
• children {string[]}: list of the plugins names (ID) that should be shown as children in the UI
• dependencies: The difference between mandatory and dependencies is the "if the parent is present" condition.). Plugins that can not be disabled (or if are hidden, added by default) and are added ONLY if the parent plugin is added. (e.g. containers like toolbar, omnibar, footer or DrawerMenu, and other dependencies like Widgets that must contain WidgetsBuilder and so on)

This JSON should have also options to match with these changes to work with extensions.
Please @mbarto @vlt1 Comment about this. I'd like to define the FULL configuration of existing plugins soon

[vlt1]

@offtherailz Unless children plugins can somehow be enabled while their parent is not, I don't think mandatoryChildren is needed and according to current mockup that is not the case. Otherwise looks fine to me.

[mbarto]

My comments:

• @offtherailz when you mention that the configuration should be generated on the server, do you want introduce a standard or geOrchestra-custom java service to handle the plugins UI configuration?

• To work with uploaded extensions, those will need to be registered in this JSON when uploaded.
  Probably it's better to separate the JS bundle and the JSON configuration into different files and upload them as a single (zip) file. This will be handled by the upload servlet / service.

[offtherailz]

@vlt1 I changed the name with "dependencies" and I suggested some of them. Typically dependencies will be hidden. I reported some examples.

@mbarto I should not develop nothing only in georchestra, because context system should be used by MapStore too. (or at least, nothing that can not be quickly implemented on mapstore, with a JSON file or something similar). Let's quickly discuss details, that we are going to report them in this issue.

[mbarto]

Some ideas for extensions upload / registration in the system:

• we should have an upload backend service, that will receive a zip with all the extensions assets (js bundle, translation, metadata json, etc.)
• the upload will unzip the extension and register it; the registration can consist into writing a record for the extension in a server index json file that will contain the list of local plugins (both pre-installed and upload) with all the metadata needed by the extension manager and other UI plugins
• the plugins / extensions index file will be loaded by the runtime in parallel with localConfig.json
• to ease externalizing this new configuration we should port the localConfig.json loader servlet into MapStore and generalize it to handle also this file

[offtherailz]

For this task we have this proposal
https://github.com/geosolutions-it/MapStore2/wiki/%5BProposal%5D:-Extension-System