Docking Tutorial: Compounding the Issue

Eleritec Docking Framework Tutorial

Table of Contents | Printer Friendly Version

Compounding the Issue

The simple case is useful in an academic sense as an introduction to docking features. However, it doesn't make much sense in a real-world application. For a complex GUI, docking features are typically enabled on regions of the screen, encompassing groups of components. Treating a single component as both drag initiator and docking source ends up making the component itself rather useless as the docking functionality would tend to interfere with normal use of the component.

A compound case involves underscoring the difference between the drag initiator and the dockable component itself. A perfect case in point would be any windowing system. For a given window (or Frame, in the Swing world), there is, among other subcomponents, a titlebar. The titlebar is the drag initiator for a window, as

shown by the necessity for dragging a window's titlebar in order to move the window itself around the screen. On the other hand, the window itself is considered to be the draggable (or, for our purposes, 'dockable') component.

The Dockable interface contains both getInitiator() and getDockable() methods. The former returns the Component responsible for initiating drag operations on the Dockable instance. The latter is the actual dockable component. In the case of our window analogy, were a window to implement the Dockable interface, getInitiator() would return the window's titlebar and getDockable() would return a reference to the window itself.

CompoundDemo.java demonstrates a compound case in which a series of JPanels contain colored labels in their NORTH region to simulate a type of embedded window (much like a JInternalFrame). These panels are similar in appearance to the View panes used by Eclipse. Each panel implements the Dockable interface, returning a reference to its

titlebar label with getInitiator() and a reference to itself via getDockable(). The titlebar text is also used by getDockableDesc(), which in turn serves as tab text in the event a panel is docked into a tabbed interface.

It is important to note that the procedure for enabling docking here is no different than in the simple case. DockingManager.registerDockable() handles docking-enablement in the same fashion as with the simple case, only a Dockable instance is registered instead of a Component.

It is also worth noting that the JPanel itself does not directly implement the Dockable interface. The Dockable interface has been designed with flexibility in mind. Unfortunately, the amount of flexibility in a system is usually inversely proportional to its simplicity. In this situation, the Dockable interface mandates implementation of a myriad of methods that aren't even relevant to such a simple, contrived example. To alleviate this problem, the DockableAdapter provides a default implementation of the Dockable interface, allowing subclassing whereby only the relevant methods need be overridden. This is what has been done in CompoundDemo.java to keep the code simple, yet still provide a valid Dockable implementation.

A Simple Dockable Demo

Basic Customization