...

|
+-- resources
|   +-- {UiExtId}
|       +-- css.html
|       +-- js.html
|
+-- webapp
    +-- app
        +-- view
            +-- {viewid1}
            |   +-- *.css
            |   +-- *.html
            |   +-- *.js
            |
            +-- {viewid2}
                +-- *.css
                +-- *.html
                +-- *.js

where UiExtId is the unique ID of the UiExtension instance, and viewid1 and viewid2 are the unique IDs of the views provided by the extension.

Server-Side Architecture

The main artifact supporting the ONOS GUI on the has a corresponding server-side presence (on each ONOS instance in the cluster) which is exposed as the UiExtensionService. The following figure illustrates the relationship between the "service", the implementing "manager", and how the "core UI extension" is composed...relationships between the various components: 

Image Added

The UiExtensionService provides an API allowing the run-time addition (or removal) of UiExtension instances. The UiExtensionManager implements this service, and automatically registers the "core" UiExtension instance (shown at the top of the figure). ONOS applications may provide their own UiExtension instance, which they will register on activation, and unregister on deactivation (shown at the bottom of the figure).

A UiExtension instance provides:

• a UiMessageHandlerFactory which generates UiMessageHandlers, each of which generate RequestHandlers.
• one or more UiViews; server side "model" objects representing a "view" in the GUI
• two .html snippets providing linkage for injected .css and .js resources

Note that there is generally a 1:1 correspondence between UiViews and UiMessageHandlers.

 Image Removed

Under review from here down.....

...