|
|
The Error Stripe shows an overview of important information of an edited source code. It shows this information for the whole source code (regardless of its size).
Question (arch-overall): Describe the overall architecture. Answer:The Error Stripe module provides an SPI for pluging in marks providers.
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:A module in the IDE has information, which can be usefully shown to the user in the error stripe (eg. (error) annotations, TODOs, etc.)
Implement the Mark to suite your needs.
Implement the MarkProvider that will provide list of Mark to be shown in the Error Stripe. Be sure it fires a PropertyChangeEvent when the list of the Marks is changed.
Implement the MarkProviderCreator that will provide create an instance of your MarkProvider for a given document and install it as described here.
A module in the IDE has information whether data (provided by some other or this one MarkProvider) shown in the Error Stripe is up-to-date or not. The Error Stripe may change the appearance according to this knowledge.
Implement the MarkProvider that will provide up-to-date status. Be sure that it fires PropertyChangeEvent when this status is changed.
Implement the MarkProviderCreator that will provide create an instance of your MarkProvider for a given document and install it as described here.
A MarkProvider may provide information that can be applied to any editor type, or it may provide infromation that applies only to a very specific type of editor.
An API user wants for create an Error Stripe component and incorporate it into his/her own component.
WARNING: THERE IS NO WAY TO DO THIS RIGHT NOW!
Question (arch-time): What are the time estimates of the work? Answer:The module and its providers are basically written. Apart from time for the API review, time will be necessary for global clean-up (2-3 working man-days), polishing of the look and feel (7 working man-days), and stabilization (7 working man-days).
There is no expected milestone.
Question (arch-quality): How will the quality of your code be tested and how are future regressions going to be prevented? Answer:The non-visual parts of the Error Stripe will be covered by the automatic unit tests. The visual parts of the Error Stripe are going to be covered by a manual test specification.
The Error Stripe module depends on the Editor - editor module. It uses this dependency to add the overview component to the editor window and to use various editor utilities.
Question (dep-non-nb): What other projects outside NetBeans does this one depend on? Answer:This module does not depend on any non-NetBeans projects (except the JRE).
Question (dep-platform): On which platforms does your module run? Does it run in the same way on each? Answer:This module runs on any platform that provides the required JRE.
Question (dep-jre): Which version of JRE do you need (1.2, 1.3, 1.4, etc.)? Answer:JRE1.4
Question (dep-jrejdk): Do you require the JDK or is the JRE enough? Answer:JRE is enough.
The Error Stripe requires only standard NetBeans module files.
Question (deploy-nbm): Can you deploy an NBM via the Update Center? Answer:The NBM can be deployed via the Update Center.
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:This module does not depend on installation directory.
Question (deploy-packages): Are packages of your module made inaccessible by not declaring them public? Answer:The Error Stripe module provides a public package org.netbeans.editor.errorstripe.spi which provides the ErrorStripeSPI - Error Stripe SPI.
Question (deploy-dependencies): What do other modules need to do to declare a dependency on this one? Answer: OpenIDE-Module-Module-Dependecies: org.netbeans.modules.editor.errorstripe/1 >@SPECIFICATION-VERSION@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:This module does neither define nor implement any standard.
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:This is the first version of this module. It does not provide any settings except keybindings.
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: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
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
The module does not use the global lookup. The module uses the lookup internally to access MarkProviderCreators.
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
System.getProperty
) property?
Answer:
org.netbeans.modules.editor.errorstripe.AnnotationView - This property sets the logging level. See org.openide.ErrorManager.getInstance for more details.
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:This module does not define any 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:No.
Question (exec-introspection): Does your module use any kind of runtime type information (instanceof
,
work with java.lang.Class
, etc.)?
Answer:
No.
Question (exec-threading): What threading models, if any, does your module adhere to? Answer:XXX no answer for exec-threading
Question (security-policy): Does your functionality require modifications to the standard policy file? Answer:The module uses org.netbeans.modules.editor.errorstripe and does not need any special priviledges.
Question (security-grant): Does your code grant additional rights to some other code? Answer:No.
No files are read or written.
Question (format-dnd): Which protocols (if any) does your code understand during Drag & Drop? Answer:The error stripe does not use Drag & Drop.
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 onjava.awt.datatransfer.Transferable
?
Answer:
This module does not work with clipboard.
No.
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:The performance depends heavily on the number of Marks provided by the MarkProviders and on the number of lines which are covered by these Marks. In the worst case, if m is the total number of Marks to be shown, p is the total number of providers and l is the total number of lines covered by the Marks, some operations can take O(n + p + l) worst-case time.
Question (perf-limit): Are there any hard-coded or practical limits in the number or size of elements your code can handle? Answer:There are not hardcoded limits. But, the number of Marks shown in the Error Stripe should be held as low as possible (while still being usefull), because the user would get confused by too many shown Marks. Also the performance of the redrawing of the Error Stripe degrades rapidly when there are many marks (~1000).
Question (perf-mem): How much memory does your component consume? Estimate with a relation to the number of windows, etc. Answer:No answer.
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:No.
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:Currently, there is no way to enforce the performance of the plugged in code.