Separate the repo structure from the repo UI model

We have to be able to create the installer UI totally independently of the installer repo structure. An architecture similar to Qt model-view framework, where the model works as an adapter to the actual repo data would allow creating an UI with different sorting and filtering criteria. 

1st Proposal:

• Installer receives component mapping json-document from the installer backend server.
• Installer displays the UI tree based on the mappings.
• There is a default UI tree, based on the default component mapping. Then there is just a delta for the changed components. The mapping instructions are needed only for the components in the delta. 
• As it would not convenient to describe the whole repo structure in the mappings, it needs to be possible in map also blocks of the repo tree.
• Mapping file could be something like this (very early draft)

       [

          { DisplayName: “Preview”,  sortPriority: 1,  Location: “preview”,  Source: “preview”, includeChilds: true , hideIfEmpty: true },

          { DisplayName: “Qt”,  sortPriority: 2, Location: “qt”, Source: “qt”,  includeChilds: true },

          { DisplayName: “Developer Tools”,  sortPriority: 3, Location: “qt.devtools”, Source: “qt.tools” },

          { DisplayName: “Designer Tools”,  sortPriority: 4, Location: “qt.design”, Source: “” },

               { DisplayName: “Designer Tools”,  sortPriority: 1, Location: “qt.design.qtdesignstudio”, Source: “qt.tools.qtdesignstudio” },

         …

       ]

• The mappings should support

• •  DisplayName & Description overwrite
  • sorting priority to define in which order items are displayed
  • hiding the node if empty
  • include Childs nodes to support “block” mapping
  • creating new items not existing in the repo structure
  • more to be defined
• On installer back server side RESP API is needed to upload/update the mapping json.