Configuration engine

Design Principles

The main idea is to provide a mechanism to describe the configuration section of the UI and the configuration of plugins that is flexible and not bound to code. To reach this the whole hs to be described with an higher level language.

##Item description Each item is described as follows:

"KEY":{
    "value":"VALUE",
    "type":"[boolean|int|string|password|page|section]",
    "label":"Blah blah"
    }

where:

• KEY [MANDATORY] identifies the item.

• VALUE [OPTINAL] this attribute contains the current item value. Its format depends on the type. For example a boolean type will contains true or false while a string type can contain any string.

• TYPE [MANDATORY] this attribute describes the data type. As of now the above values are supported. More can (and will) come in the future.

• LABEL [MANDATORY] This attribute contains the label associated to the item, in the locale specified by the caller

##Linking items in a hierarchy Items can be linked in a tree hierarchy. To do this the attribute children is specified. Its value is an object containig subitems. Below an example:

'main':{
"type":"page",
"label":"Configuration"
"children":{
    "sub_page_a":{
        "type":"page",
        "label":"Network configuration"
        },
    "sub_page_b":{
                "type":"page",
                "label":"System configuration"
                "children":{}
                },
            }
        }

The above example describes a main page linking two sub pages

##Nesting configuration items into the hierarchy A configuration value, coming for example from plugin config, can be nested by putting it as children of one of the nodes. Indeed plugin use the same exact grammar for describing their configuration parameters. Thus their configuration can be esaily nested in the above description without any modification.

##Saving configuration When saving configuration the client has to provide the updated piece of configuration and its path (unix fs style) inside the whole hierarchy. For example,having the following hierarchy:

"main":{
    "type":"page",
    "label":"Configuration"
    "children":{
        "sub_page_a":{
            "type":"page",
            "label":"Network configuration",
            "children":{
                    "wifi":{
                        "value":"true",
                        "type":"boolean",
                        "label":"Enable Wifi"
                        }
                }
            },
        "sub_page_b":{
                    "type":"page",
                    "label":"System configuration"
                    "children":{}
                    },
                }
            }

The UI will shot a page under the "Network confiugration" section with one check box, whose label is "Enable Wifi". When saving, the UI will send the following configuration:

"wifi":{
         "value":"false",
         "type":"boolean",
         }

specifying the path /main/sub_page_a