General Information
Question (arch-what):
What is this project good for?
Answer:
Multi views are general mechanism for displaying several perspectives, or views of data,
which will be used consistently across whole IDE window system. Using multi views
will enable modules to visually represent data document or object in unified manner
at one specific place in the system, yet still allowing for different perspectives
of data viewing.
Question (arch-overall):
Describe the overall architecture.
Answer:
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.
Question (arch-usecases):
Describe the main
use cases of the new API. Who will use it under
what circumstances? What kind of code would typically need to be written
to use the module?
Answer:
There is an introduction to MultiView and its usage in its
javadoc. It covers the major part
of available usecases.
Here is just
a list of frequently asked or interesting questions slowly expanding as
people ask them:
MultiView faq:
How does serialization work?
Q:
How does serialization of multiviews work and what needs to be serializable?
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.
How to set the display name?
Q:
How do I set the display name for 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.
Question (arch-time):
What are the time estimates of the work?
Answer:
Total time estimate is 4 months. First two months is design and implementation phase,
other two months are reserved for stabilization phase. One developers will work
on the project. Final milestones are aligned with milestones of cdp promotion D
product.
Question (arch-quality):
How will the quality
of your code be tested and
how are future regressions going to be prevented?
Answer:
We are going to use standard unit tests. Unit tests should include tests of
MultiViewElement implementation method calls sequence, number of calls. Further
way tests of whole MultiViewTopComponent loading/storing, tests of proper config
xml reading.
Question (arch-where):
Where one can find sources for your module?
WARNING: Question with id="arch-where" has not been answered!
Project and platform dependencies
Question (dep-nb):
What other NetBeans projects and modules does this one depend on?
Answer:
MultiViews project depends on Window System API, namely org.openide.windows.TopComponent
API.
It also depends on some new APIs in openide, namely NbDocument.CustomToolbar and CloneableEditorSupport.Pane
The default answer to this question is:
These modules are required in project.xml:
-
CommonAnnotationsAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
1.13
is required.
-
MimeLookupAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
1.11
is required.
-
org.openide.awt
-
The module is needed for compilation.
The module is used during runtime.
Specification version
6.2
is required.
-
DialogsAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
6.2
is required.
-
FilesystemsAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
9.0
is required.
-
NodesAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
7.23
is required.
-
EditorAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
6.39
is required.
-
UtilitiesAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
9.3
is required.
-
WeakListener.setAccessible
-
The module is needed for compilation.
The module is used during runtime.
Specification version
9.3
is required.
-
LookupAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
8.0
is required.
-
WindowSystemAPI
-
The module is needed for compilation.
The module is used during runtime.
Specification version
6.52
is required.
Question (dep-non-nb):
What other projects outside NetBeans does this one depend on?
Answer:
This project doesn't depend on any outside Netbeans projects.
Question (dep-platform):
On which platforms does your module run? Does it run in the same
way on each?
Answer:
Module MultiViews should run on all platforms IDE is able to run, no restrictions
are planned. It runs the same on all platforms expect LF code. It's expected that
look and feel code will have to be slightly different for supported OS. Chnages
are expected to be as small as possible, touching only drawing, not behaviour.
Question (dep-jre):
Which version of JRE do you need (1.2, 1.3, 1.4, etc.)?
Answer:
XXX no answer for dep-jre
Question (dep-jrejdk):
Do you require the JDK or is the JRE enough?
Answer:
XXX no answer for dep-jrejdk
Deployment
Question (deploy-jar):
Do you deploy just module JAR file(s) or other files as well?
Answer:
Just one module jar.
Question (deploy-nbm):
Can you deploy an NBM via the Update Center?
Answer:
Yes.
Question (deploy-shared):
Do you need to be installed in the shared location only, or in the user directory only,
or can your module be installed anywhere?
Answer:
XXX no answer for deploy-shared
Question (deploy-packages):
Are packages of your module made inaccessible by not declaring them
public?
Answer:
Yes, they will be.
Question (deploy-dependencies):
What do other modules need to do to declare a dependency on this one,
in addition to or instead of the normal module dependency declaration
(e.g. tokens to require)?
Answer:
Nothing.
Compatibility with environment
Question (compat-i18n):
Is your module correctly internationalized?
Answer:
The module itself doesn't expose anything brandable (at least to my knowledge.)
Question (compat-standards):
Does the module implement or define any standards? Is the
implementation exact or does it deviate somehow?
Answer:
No.
Question (compat-version):
Can your module coexist with earlier and future
versions of itself? Can you correctly read all old settings? Will future
versions be able to read your current settings? Can you read
or politely ignore settings stored by a future version?
Answer:
XXX no answer for compat-version
Question (compat-deprecation):
How the introduction of your project influences functionality
provided by previous version of the product?
WARNING: Question with id="compat-deprecation" has not been answered!
Access to resources
Question (resources-file):
Does your module use 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.
Question (resources-mask):
Does your module mask/hide/override any resources provided by other modules in
their layers?
Answer:
No.
Question (resources-preferences):
Does your module uses preferences via Preferences API? Does your module use NbPreferences or
or regular JDK Preferences ? Does it read, write or both ?
Does it share preferences with other modules ? If so, then why ?
WARNING: Question with id="resources-preferences" has not been answered!
Lookup of components
Execution Environment
Question (exec-property):
Is execution of your code influenced by any environment or
Java system (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
Format of files and protocols
Question (format-types):
Which protocols and file formats (if any) does your module read or write on disk,
or transmit or receive over the network? Do you generate an ant build script?
Can it be edited and modified?
Answer:
Standard topcomponent serialization is used.
Question (format-dnd):
Which protocols (if any) does your code understand during Drag & Drop?
Answer:
No DND.
Question (format-clipboard):
Which data flavors (if any) does your code read from or insert to
the clipboard (by access to clipboard on means calling methods on java.awt.datatransfer.Transferable?
Answer:
No Clipboard operations.
Performance and Scalability
Question (perf-startup):
Does your module run any code on startup?
Answer:
No. Except for deserialization of opened components.
Question (perf-exit):
Does your module run any code on exit?
Answer:
No.
Question (perf-scale):
Which external criteria influence the performance of your
program (size of file in editor, number of files in menu,
in source directory, etc.) and how well your code scales?
Answer:
Perfomance of MultiViewTopComponent is influenced by performance of components
that will act as individual MultiViewElements. From what we know today that means
performance of Editor, Form Editor, Component Palette, Property Sheet, VCS Outputs,
To Do list. Also number of view elements affect performance of MultiViewTopComponent.
The separation of MultiViewElement and MultiViewDescription interfaces is meant to allow lazy creation of not
visible components and providing them on demand. This should influence first usage performance.
Question (perf-limit):
Are there any hard-coded or practical limits in the number or size of
elements your code can handle?
Answer:
Yes, there are practical limits enforced in visual design. Number of different
view elements for one tab (MultiViewTopComponent) must not exceed 7 or 8,
according to the HIE.
Data model underneath will not have such limit, will use standard java collections.
Question (perf-mem):
How much memory does your component consume? Estimate
with a relation to the number of windows, etc.
Answer:
XXX no answer for perf-mem
Question (perf-wakeup):
Does any piece of your code wake up periodically and do something
even when the system is otherwise idle (no user interaction)?
Answer:
No.
Question (perf-progress):
Does your module execute any long-running tasks?
Answer:
XXX no answer for perf-progress
Question (perf-huge_dialogs):
Does your module contain any dialogs or wizards with a large number of
GUI controls such as combo boxes, lists, trees, or text areas?
Answer:
No.
Question (perf-menus):
Does your module use dynamically updated context menus, or
context-sensitive actions with complicated and slow enablement logic?
Answer:
XXX no answer for perf-menus
Question (perf-spi):
How the performance of the plugged in code will be enforced?
Answer:
MultiViewTopComponent probably should load just active MultiViewElement completely,
loading inactive view elements lazily.
Javadoc comments in MultiViewElement interface will notify developers to keep
perf-important methods fast executed.