NetBeans Architecture Answers for multiview module

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. Further documents are Overall Programmatic Design and Visual Specification Draft.
Question (arch-overall): Describe the overall architecture.
Answer: Design is discussed in separate design document, accompanied by simple diagram.
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: According to the Visual Specification Draft , Multi Views are going to be used in Editor, Component Palette, Property Sheet, VCS Outputs, To Do list. Note that list may be not complete.
Modules will typically either implement MultiViewElement interface from scratch or convert their existing TopComponent subclasses to implement MultiViewElement interface. Modules will also put XML config files into their layers. XML config files describe properties of individual Views, such as their names, icons, MultiViewElement implementation entry point.
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. Two 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.

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.
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: XXX no answer for deploy-jar
Question (deploy-nbm): Can you deploy an NBM via the Update Center?
Answer: XXX no answer for deploy-nbm
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?
Answer: XXX no answer for deploy-dependencies

Compatibility with environment

Question (compat-i18n): Is your module correctly internationalized?
Answer: XXX no answer for compat-i18n
Question (compat-standards): Does the module implement or define any standards? Is the implementation exact or does it deviate somehow?
Answer: XXX no answer for compat-standards
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

Access to resources

Question (resources-file): Does your module use java.io.File directly?
Answer: XXX no answer for resources-file
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: XXX no answer for resources-layer
Question (resources-read): Does your module read any resources from layers? For what purpose?
Answer: XXX no answer for resources-read
Question (resources-mask): Does your module mask/hide/override any resources provided by other modules in their layers?
Answer: XXX no answer for resources-mask

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: This is not known yet. Probable places where Lookup could be used are aggregating MultiViewTopComponent with MultiViewElement impl instances and data context awareness of MultiViewElement implementations.
Question (lookup-register): Do you register anything into lookup for other code to find?
Answer: XXX no answer for lookup-register
Question (lookup-remove): Do you remove entries of other modules from lookup?
Answer: XXX no answer for lookup-remove

Execution Environment

Question (exec-property): Is execution of your code influenced by any environment or Java system (System.getProperty) property?
Answer: XXX no answer for exec-property
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-classloader): Does your code create its own class loader(s)?
Answer: XXX no answer for exec-classloader
Question (exec-reflection): Does your code use Java Reflection to execute other code?
Answer: XXX no answer for exec-reflection
Question (exec-privateaccess): Are you aware of any other parts of the system calling some of your methods by reflection?
Answer: XXX no answer for exec-privateaccess
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: XXX no answer for exec-process
Question (exec-introspection): Does your module use any kind of runtime type information (instanceof, work with java.lang.Class, etc.)?
Answer: XXX no answer for exec-introspection
Question (exec-threading): What threading models, if any, does your module adhere to?
Answer: XXX no answer for exec-threading

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?
Answer: XXX no answer for format-types
Question (format-dnd): Which protocols (if any) does your code understand during Drag & Drop?
Answer: XXX no answer for format-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: XXX no answer for format-clipboard

Performance and Scalability

Question (perf-startup): Does your module run any code on startup?
Answer: XXX no answer for perf-startup
Question (perf-exit): Does your module run any code on exit?
Answer: XXX no answer for perf-exit
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.
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: XXX no answer for perf-wakeup
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: XXX no answer for perf-huge_dialogs
Question (perf-menus): Does your module use dynamically updated context menus, or context-sensitive actions with complicated 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. Also separation of view element properties into xml config files will help to lazily instantiate MultiViewElement implementations. Javadoc comments in MultiViewElement interface will notify developers to keep perf-important methods fast executed.