Defines the module abstraction, and in particular, ModuleInstall, a class that modules can use to do any work they need to do on startup, shutdown, installation, or removal.

Should be implemented by a module’s main class and identified in the manifest tag OpenIDE-Module-Install. This class contains methods you can implement if your module needs to do custom initialization or cleanup when it is installed, uninstalled, or when the IDE is started or shut down.

Note that many modules will not need a ModuleInstall class. Most common things a module will need to do on install, uninstall, startup, and shutdown can be specified declaratively in XML.

Nodes live in a tree-like hierarchy; nodes can have a parent (containing) node and child nodes. These are supplied by an instance of the class Children owned by the node and retrieved via the method someNodeInstance.getChildren( ).

In the JavaBeans spec, properties are determined at compile time, depending on method signatures. Properties of nodes are instances of Node.Property and can potentially change at runtime. If you want to represent a standard JavaBean as a node, this is quite easy using the BeanNode wrapper class.

A node has a set of actions that can be performed on it, which may vary depending on the state of the object it represents.

A node has a set of cookies, which are objects that implement the Node.Cookie marker interface. A cookie is an arbitrary Java class instance that can provide access to objects relating to the node. A cookie can be any Java object that is useful to expose to other code that might interact with the Node. For example, a cookie may implement actions that can be performed on the Node by the user, or provide structural access to the data in the underlying DataObject. Cookies are retrieved by passing the Class object for the desired interface to someNode.getCookie(Class clazz) and casting the result (if non-null) to that interface.

For example, a node representing a file the user has opened in the Editor will provide an EditorCookie. The EditorCookie implementation that is returned provides both methods for opening the document in the editor and for accessing the document object the editor uses, finding all open editor panes that are editing this file, and other editing-related functionality.

An object that encapsulates one or several files. If the data it represents is structured, a common thing for a DataObject to do is to provide structural, programmatic representations of the data via its Cookies.

Factories for DataObjects. When NetBeans encounters a new file, it figures out what type of data it is and invokes the DataLoader for that type of data to create a DataObject to represent it.

Why is a layer between files and nodes needed? One of the most compelling reasons is that it may be desirable to present multiple files as a single object. In practice, almost all data objects extend MultiDataObject, even though only one file can be contained in the object.

A DataObject implementation that represents a folder that contains other DataObjects.

A Node implementation that represents a DataObject.

Registers a set of extensions or MIME types and is responsible for loading data from files of these types.

Similar to UniFileLoader, but responsible for loading data from multiple files that should be represented as a single entity within NetBeans (for example, a Java source file with an associated compiled class file and possibly an XML form file that defines the GUI layout). Almost all loaders extend MultiFileLoader.

This class implements methods from OpenCookie, ViewCookie, and CloseCookie, but does not declare itself to implement any of these interfaces. To implement any of these cookies, simply subclass OpenSupport and declare your subclass to implement any of the interfaces it supports. OpenSupport provides generic support for opening documents. Depending on the type of editor(s) to be instantiated, this functionality may be better referred to as Viewing, Opening, or Editing.

This class is particularly useful if you need to create a component that assembles itself from instances or subfolders in a folder. FolderInstance contains logic for accepting or rejecting instances contained in that folder, or for overriding the supplied instance (this is the mechanism by which it is possible to paste compiled classes into menus and toolbars). In particular, it is sensitive to the addition or deletion of files within the folder and can be used to rebuild the component in question with minimal coding on the part of the module author. For a good example of its usage, see the sources for org.openide.awt.MenuBar .

Contains GUI components that can represent Nodes graphically, including tree, menu, drop-down, list, and table views. An Explorer view is created and is given a root node. Some views display the root node and its children (perhaps recursively). Others display nodes contained in the explored context (another parent node). Still others display the selected node (or nodes) only.

This interface is the entry point for communicating with Explorer views. An ExplorerManager tracks changes in the node selection, as well as the root node and explored context, for one or more Explorer views associated with it. To listen for changes on an open Explorer view, attach a listener to its manager.

A very convenient visual class that you can use to create compound components that contain one or more Explorer views. ExplorerPanel extends org.openide.windows.TopComponent, the base class for dockable windows in NetBeans, and implements ExplorerManager.Provider (a way of finding ExplorerManagers). To associate an Explorer view with the ExplorerPanel so you can listen to it for changes in selection, and so on, simply add your view to the ExplorerPanel as a Swing component.

This package contains classes that are responsible for property sheets in NetBeans. Property sheets and instances of the PropertyPanel class in this package provide one of the primary ways for users to adjust settings and attributes of objects in NetBeans. NetBeans contains some enhancements to the JavaBeans property editor infrastructure. Also present is the PropertySheetView visual class, an Explorer view that, when given a node selection from an explorer manager, displays the user-editable properties of that node (or set of nodes) as a familiar property sheet.

This is the standard tree view you see in the main Explorer window in the IDE, as shown in Figure 15-4.

A drop-down list component that displays an Explorer tree to some fixed depth, as shown in Figure 15-5.

Figure 15-5. Explorer views—ChoiceView

A component that displays nodes as icons, reminiscent of the Microsoft Windows Explorer (see Figure 15-6). This class is not used in the current NetBeans distribution, but was part of the original New Wizard and is maintained as part of the APIs.

Figure 15-6. Explorer views—IconView

Displays the children of one Node in a flat list, without indentation, illustrated in Figure 15-7.

Figure 15-7. Explorer views—ListView

This view presents a set of Nodes in a menu, with submenus for nodes that have children (see Figure 15-8).

Figure 15-8. Explorer views—MenuView

This looks the same as BeanTreeView, but there is a significant difference. When you select a node in this view, the ExplorerManager managing the Explorer views changes the explored context for all other Explorer views to the node you have selected in your ContextTreeView component. If you’ve used Windows, think of Windows Explorer here, with its left-hand pane to select the current directory and its right-hand pane to display that directory’s contents. By changing the context for all other components managed by its manager, you can actually create a component very much like the Windows Explorer within NetBeans, as seen in Figure 15-9.

Figure 15-9. A “Pseudo-Windows Explorer” mock-up created using IconView and ContextTreeView

It is not uncommon in NetBeans to have a dialog box or window that displays a number of nodes, the purpose being to configure only a few properties of all of these nodes. An example of this is the panel for enabling and disabling modules in the Setup Wizard.

This class provides a flexible way to display specific properties of a given set of Nodes in a table alongside a tree. A TreeTableView displays a tree view of nodes, and can be given one or more properties (if present) to display for each node in the tree. What is displayed in the view depends on the model supplied to the tree and the array of property names provided for the component to expose. Take a look at Figure 15-10 for an idea of this view.

Figure 15-10. Explorer views—TreeTableView

All actions in NetBeans subclass SystemAction, which is an extension to the Swing action API, extending the Open APIs class SharedClassObject and expecting to be a singleton.

A convenience base class for non-context-sensitive actions. Implementing a single abstract method allows your action to be invoked.

An action which has a separate performer object associated with it that actually performs the action. The performer can be changed on the fly. This is typically used for actions whose meaning depends on the selected window. When no performer is present, the action is disabled.

An action which can listen to what the currently selected node is, and set its enabled state accordingly.

This very useful base class provides an action whose state is enabled or disabled depending on what Node.Cookie classes are held by the activated nodes.

An object that represents a group of related user-modifiable settings (exposed through the SystemOption subclass’s bean properties).

A SystemOption that is a container for additional child SystemOptions.

NetBeans does not assume compilation is a one-step process. A compiler job consists of a set of compilers with possible dependencies on one another. Compilation may proceed in one or more stages, each of which can run varied compilation procedures.

An object that represents one compilable file or other unit in a compiler group.

An object that represents one step in a compiler job, perhaps compiling a cluster of similar files.

A ServiceType that has a method for contributing to a compiler job.

A cookie implementation that, when present in a node’s cookie set, indicates that the thing represented by the node can be compiled. Provides methods for adding a DataObject to a compiler job.

A base class that can provide implementations of the following Cookie interfaces as needed:

A class that extends CloneableEditorSupport to support associating an editor with a DataObject representing the file or files to be edited.

This is a utility class with static methods and interfaces for handling NetBeans’ document conventions.

Represents one line in a document. If a reference to a Line object is held, it will continue to represent the same line of text, even if the document is altered so that its position in the document has changed.

This is the base class for objects representing some user-presentable marker that applies to a line or part of a line within a document. The graphic displayed in the Editor’s line-number gutter and background color of a line in a Java file that has been set as a breakpoint is an example of an annotation. Another example is the highlighting that occurs when you click a compiler error in the Output Window.

UI components can be mixed inside a window, with tabs to access the different components. Components can also be docked into the sides, top, and bottom of windows that support this, such as the Editor window.

Support for discrete sets of windows organized by task.

SDI (single document interface) means you have multiple windows on the screen. MDI (multiple document interface) means that there is one large window with subwindows inside that window.

A workspace is a set of open windows, their contents, positions, and frame styles. To get the current workspace, call TopManager( ).getDefault( ).getWindowManager( ).getCurrentWorkspace( ). Workspaces contain Modes.

An interface representing a window containing GUI components. Modes define docking. Windows may contain multiple components on a tabbed pane or components that are docked into the top, bottom, left, right, or the center of the window (using draggable splitters so the user can adjust the relative sizes). Generally, modules don’t need to interact directly with the mechanics of modes; however, if there’s a particular window, such as the Explorer or Editor windows, that you want your component to open in, you can locate that Mode by calling Mode mode = TopManager.getDefault( ).getWindowManager( ).findMode(String name) and add your TopComponent to it by calling the dockInto( ) method with your component as the argument.

Modes contain one or more TopComponents. This can also be done via XML layers, as explained at the end of this list.

This is the base class for all dockable window components in the IDE. A TopComponent is a generic GUI container component, subclassing javax.swing.JComponent. The difference is that it has the hooks to be connected to NetBeans’ window management system (see Figure 15-11 for a big-picture view).

Figure 15-11. Modes, TopComponents, and Nodes—anatomy of the Explorer window

This is the class that actually handles the opening and closing of TopComponents and the docking behavior of Modes and that you can listen to for changes in the current workspace and available set of workspaces. To get the default instance, call TopManager.getDefault( ).getWindowManager( ).

This is another singleton class; it has methods you can call to get the set of currently active nodes. All TopComponents instantiated in NetBeans are registered here. When a TopComponent gets input focus, it becomes the “active” TopComponent and gains control over what the active nodes are. The active nodes are used in turn to enable or disable functionality (such as menu items) depending on what nodes the user has selected. To get this registry, call TopManager.getDefault( ).getWindowManager( ).getRegistry( ).

A cookie class that has a single method called open( ), which tells NetBeans to open an object (normally in an editor, whether as text or graphically).

A cookie to allow access to a document object and the editor instances that have the document open and determine if the document is modified.

A cookie with a single method save( ) to instruct NetBeans to save an object.

Some Nodes, such as JavaBeans on the Form Editor’s Component Palette, are able to create instances of some arbitrary object (for example, when you drop a JButton on a form). InstanceCookie provides support for creating this instance via its instanceCreate( ) method. Another powerful use of InstanceCookie is its use to create a node that represents a Java class instance without NetBeans having to load that class unless something actually calls instanceCreate( ).

Objects representing Java source files will have a SourceCookie providing access to a SourceElement object, which has methods such as getClasses( ) and getImports( ), which give the caller structured access to the contents of that source file.

A class that is able to launch an execution process via its execute(DataObject obj) method.

Launches an external process including passing command-line arguments.

Launches a process in a new thread in the VM in which NetBeans is running.

NetBeans can support a variety of scripting languages, such as Jython, via the Scripting module. This class provides basic support for executing a script.

An implementation of ExecCookie and DebuggerCookie, which provide methods to execute and debug objects such as Java classes.

The top-level container representing an entire source file, which can be retrieved via SourceCookie. It contains ClassElements.

Represents a Java class or interface. It contains MemberElements.

Comprises the appropriately named ClassElement (for named inner classes), MethodElement, FieldElement, or ConstructorElement.

A base class for structural elements of source files, such as fields, methods, classes, and so on.

A class to represent an initializer section in a Java file, for example:

public class MyClass {
  static {
    doSomething( );
  }
}

Represents an import statement in a source file.

Represents an identifier, such as String or com.foo.MyClass.

A provider to allow mounting of local directories.

Access to files within a JAR or ZIP archive.

Access to “files” that are really entries in an XML file in a predefined format.

Allows for access to a remote CVS (Concurrent Versioning System) repository, and all the common operations done in CVS. The implementation is written entirely in Java, using the JavaCVS library (http://javacvs.netbeans.org/library/index.html).

This module supports access to a variety of version control systems by defining commands that launch that system’s utilities in a shell and parse the output of the external process.

The abstract base class that all filesystems (such as local, ZIP/JAR, CVS) extend. FileSystem is the interface module that code will use to interact with any filesystem.

An abstraction for a file. FileObjects also support annotations, which allow, for example, a version control system to expose the information that a file is out of date. FileObjects can have attributes that go beyond the typical operating system file attributes. Arbitrary Java objects may be added to a FileObject as named attributes.

This is a base class that makes implementing a new filesystem much easier than if you subclass FileSystem directly. It contains a few simple interfaces that, when implemented, will take care of most of the work of interfacing to a new kind of storage system.

Files in NetBeans are identified by their MIME type. When you write a DataLoader to load a new file type, you may need to create and register a MIMEResolver. When NetBeans encounters a new file type, it queries the pool of available resolvers. If a resolver recognizes the file type, it will provide an appropriate DataLoader for the file. There is a declarative syntax for defining MIMEResolvers in XML, described in the Open APIs documentation and covered in this book in Chapter 21.