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
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:

• UtilitiesAPI - The module is needed for compilation. The module is used during runtime. Specification version 6.2 is required.
• NodesAPI - The module is needed for compilation. The module is used during runtime. Specification version 6.2 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.
• WindowSystemAPI - The module is needed for compilation. The module is used during runtime. Specification version 6.2 is required.
• EditorAPI - The module is needed for compilation. The module is used during runtime. Specification version 6.16 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: No.
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

Question (lookup-lookup): Does your module use 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.

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: No.
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: yes. It's retrieving value of a setting property (visibility of toolbar in editor) and is listening on changes. That's an undeclared dependency on editor(org.netbeans.editor.Settings). A test is included in commit validation that checks the editor code changes.
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.