Creating a new Explorer view

Anyone may create a new Explorer view and use it for special purposes with a custom UI, to provide an alternate representation of nodes suited to some particular application. For example, you may require that your view only display a root node of a certain class which has added behaviors used in display. As a rule, it is preferable to add special functionality directly to the node if that is possible, and to use a special Explorer view only when a truly different means of display is required.

An Explorer view may be any visual component; it need not implement any particular interface, etc. However, the convention is that it keep track of the Explorer manager that controls it; this manager should be located when it is added to a parent component, by calling ExplorerManager.find(...), and then use that manager's properties to control it; the view should also stop consulting the manager when the component is removed from its parent.

The view will want to use a property change listener to keep track of what the manager expects it to do; possibly it could also veto certain changes.

Other than these requirements, nearly any visual representation is possible, and so the API does not specify any more than this.

Subclassing the tree views

The abstract base class TreeView may be used to create a specialized view based on the normal visual metaphor of an expandable tree of nodes being explored. Many customizations to it may be done by modifying the model it uses to determine which nodes are to be displayed. Or, one of its implementations may be fine-tuned: BeanTreeView provides the usual Explorer view; ContextTreeView provides something similar but only displaying non-leaf nodes (which may be useful as one panel of a multi-paned UI setup, also including a list view pane).