See: Description
| Package | Description |
|---|---|
| org.netbeans.core.api.multiview |
MultiView API lets the developers create new multiview components
(without specifying their content), manipulate existing multiview
components, eg.
|
| org.netbeans.core.spi.multiview |
MultiView SPI provides infrastructure for creating components that dock
multiple views into one consistent component.
|
| org.netbeans.core.spi.multiview.text |
MultiView Text provides integration between multi view
infrastructure and common textual framework.
|
MultiView Provides support for creation of editors composed from multiple (independent) elements. One can either specify the elements directly or read them from a declarative registration for a particular mime type.
It is possible to add/remove multiview elements at runtime.
Should a MultiViewElement allow spliting? Some applications may need that, some don't. There is a branding API to control such behavior now.
The processor for
MultiViewElement.Registration now checks validity of
provided iconBase (not on JDK6 due to bug in javac).
Also the attribute was made optional.
Toolbar can be hidden completely. To compensate that new tab switching action is available in popup of multi view components by default.
Common support class for integrating multi view and text infrastructure.
New factory methods to create multiview components for a given mime type.
Declarative way to register MultiViewElement via Registration annotation.
First of all, you don't need to worry about serialization if all your MultiViewDescription instances
contained in the multiview state to be non serializable.
Meaning they all return TopComponent.PERSISTENCE_NEVER in MultiViewDescription.getPersistenceType().
If at least one of the views requires serialization, you have no choice but to make all
MultiViewDescription implementors serializable.
You also can persist the MultiViewElement instances that the multiview contains. The algorithm here is a bit complicated for
performance reasons. Only those Elements are stored that were created during the session and which are Serializable.
So if the user never switches to the 4rd tab, and it's corresponding element and visual component never get created, then
it won't be stored. (We would have to create it just for the sake of persistance).
So if your visual component needs some inital context for creation, you should store it in the description instance, and if the visual component
wants to store it's state (location of cursor, selected field, something else that makes sense for the opened component) you should store it in the MultiViewElement.
So basically if you are always able create the Element from Description without any persisted data, you don't need to persist anything.
If you define your own CloseOperationHandler implementation for the multiview component, then you also ought to define it
Serializable. Otherwise it will be silently replaced by the default handler on restoration of the multiview component.
Each MultiViewDescription defines display name and icon. While the icon
is meant for the whole document/view tab, the display name is just for the inner switching button.
So how does one set the name for the whole MultiView component? It can be done when creating the component.
TopComponent mvtc = MultiViewFactory.createMultiView(myDescriptions);
mvtc.setDisplayName("My static mvtc displayName");
Later in the lifecycle of the component, it can be also influenced from within the individual
multiview visual elements using the MultiViewElementCallback.updateTitle() method.
|
|
|
Read more about the implementation in the answers to architecture questions.