Bug 518524

Description Pierre-Charles David 2017-06-20 11:42:06 EDT

The aird editor is a multi-page editor, even though in Sirius 5.0 we only support a single, hard-coded one.

We should make it extensible so that additional pages can be added. Some requirements:
* The extensibility should be designed primarily as a dynamic mechanism, controllable through APIs. There will probably be an extension point for static configuration, but it should not be the only/primary configuration mechanism.
* It should be possible not only to add new pages, but to control the order of the pages, including putting a different page that the current hard-coded "Overview" as the first/default.
* It should be possible to *replace* the "Overview" page, so that the editor is still present and has its normal behavior/lifecycle, but the actual content is different (for example to be replaced by a business-oriented overview for users that would be lost with the technical details about models/resources/viewpoints/representations...).
* It should be possible for different sessions to have different sets of pages.
* It should be possible for the set/order of pages to change dynamically during the lifecycle of a session depending on its state (at least depending on which viewpoints are enabled).

First thoughts:
* When the editor is opened, it is attached to a given session. It should be from the session's content that we determine which pages to display and in which order.
* One possible source of pages could be the VSMs of the viewpoints enabled in the session, in a way similar to what was done for properties views. The end-game of the activity explorer integration (see bug #509735) is to have "activity descriptions" configured inside the VSMs and contributed as pages to this editor, and it will be through this mechanism. Note that this source of pages can be dynamic, e.g. when viewpoints are enabled/disabled.
* Another possible source of pages would be an extension point, with more static configuration. Some "enablement" expression will be needed to control in which sessions the pages should be visible.
* One possible hard-coded extension using the previous extension point would read existing activity explorer's pages/sections/activities to contribute these pages. This is the "backward compatibility" part of bug #509735).