|
|
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.
The default answer to this question is:
These modules are required in project.xml:
java.io.File directly?
Answer:
No.
Question (resources-layer):
Does your module provide own layer? Does it create any files or
folders in it? What it is trying to communicate by that and with which
components?
Answer:
No.
Question (resources-read):
Does your module read any resources from layers? For what purpose?
Answer:
MultiViewElement.Spliting.Enabled
-
By default a MultiViewElement allows the containing TopComponent to split it.
Some systems may however find this not of any use. Then they should brand the
MultiViewElement.Spliting.Enabled to false. NetBeans IDE
by default does allow spliting.
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
No.
Question (lookup-register):
Do you register anything into lookup for other code to find?
Answer:
No.
Question (lookup-remove):
Do you remove entries of other modules from lookup?
Answer:
No.
System.getProperty) property?
On a similar note, is there something interesting that you
pass to java.util.logging.Logger? Or do you observe
what others log?
Answer:
multiview.toolbarVisible
-
The visibility of toolbar is controlled by a preference shared with editor module. The multiview implementation listens and uses following property:
MimeLookup.getLookup(MimePath.EMPTY).lookup(Preferences.class).getBoolean("toolbarVisible", true);
to find out whether all toolbars in all multiviews should be visible or not. Also, since 1.25, the toolbar is hidden completely. There is a tab switching action in multi view component popup menu to compensate this.
Question (exec-component): Is execution of your code influenced by any (string) property of any of your components? Answer: XXX no answer for exec-component Question (exec-ant-tasks): Do you define or register any ant tasks that other can use? Answer:XXX no answer for exec-ant-tasks
Question (exec-classloader): Does your code create its own class loader(s)? Answer: No. Question (exec-reflection): Does your code use Java Reflection to execute other code? Answer: No. Question (exec-privateaccess): Are you aware of any other parts of the system calling some of your methods by reflection? Answer: No. Question (exec-process): Do you execute an external process from your module? How do you ensure that the result is the same on different platforms? Do you parse output? Do you depend on result code? Answer: Nothing is executed. Question (exec-introspection): Does your module use any kind of runtime type information (instanceof,
work with java.lang.Class, etc.)?
Answer:
Action.getClass() is called in MultiViewTopComponent on actions from the element to check for Window system
related actions, if these are found, the element itself is a topcomponent and we need to replace it's actions with the MultiViewTopComponent ones.
Otherwise the action will not be trigger on the whole MVTC.
Question (exec-threading):
What threading models, if any, does your module adhere to? How the
project behaves with respect to threading?
Answer:
All calls are expected to be made from Swing AWT event thread.
Question (security-policy):
Does your functionality require modifications to the standard policy file?
Answer:
XXX no answer for security-policy
Question (security-grant):
Does your code grant additional rights to some other code?
Answer:
XXX no answer for security-grant
java.awt.datatransfer.Transferable?
Answer:
No Clipboard operations.
Built on April 24 2018. | Portions Copyright 1997-2018 Oracle. All rights reserved.