![]() |
||
|
Eleritec Docking Framework Tutorial
|
||
|
||
|
The BorderManager Interface
The BorderManager is designed to manage borders for a specified DockingPort under four different situations. The DefaultDockingPort is responsible for determining its current state and invoking the appropriate BorderManager method, and this happens without any intervention from application code.
BorderManager has a method managePortNullChild(DockingPort port) to handle container changes in which the specified DockingPort no longer has any child component docked within it. In this case, it may be desireable to remove all borders from the DockingPort, which would show an empty space on the screen. Or it may be desireable to set a special border to indicate visually that a DockingPort exists in the region and is available for docking. The descision is left to the discretion of the individual developer. The managePortSimpleChild(DockingPort port) method is used for container state changes in which the specified DockingPort ends up with a single child component docked within it. This excludes any cases in which said child component is a JTabbedPane or JSplitPane. In this case, it may be desireable to remove any border from the component itself and set a special border around the specified DockingPort, or vice versa. The point, though, is that this method gives the developer an opportunity to assign a border to one Component and not the other, thus avoiding a situation with nested borders that would detract from the overall end user experience. The managePortTabbedChild(DockingPort port) method is used for container state changes in which the specified DockingPort ends up with a JTabbedPane as its currently docked component. This method may be treated similarly to the managePortSimpleChild(DockingPort port) situation with the exception that invoking getDockedCompoent() against the specified DockingPort will yield the embedded JTabbedPane. This gives the developer opportunity to manage not only the DockingPort border and the JTabbedPane border, but also the border for each component embedded within the JTabbedPane itself. Finally, the managePortSplitChild(DockingPort port) method is used for container state changes in which the specified DockingPort ends up with a JSplitPane as its currently docked component. This method is extremely useful in that, when a JSplitPane is present, by definition, some level of nested docking is taking place. Invoking getDockedCompoent() against the specified DockingPort will yield the embedded JSplitPane. The method imlementation may then proceed to manage the border for the DockingPort, the JSplitPane, the JSplitPane divider, and each component embedded within the JSplitPane. This is, in practice, much less complicated than it may sound. One may, for instance, remove the border on the DockingPort, JSplitPane, and the divider, and set a border on each of the docked components to visually separate them from each other. But further border management down the container hierarchy to drill down inside of child DockingPorts is unnecessary. The very act of docking against a DockingPort implies that the specified DockingPort is, indeed, the deepest split DockingPort within the hierarchy. Sub-docking within the container hierarchy will be handled automatically by subsequent BorderManager calls as child DockingPorts manage their own docking operations. This greatly simplifies the code necessary for a decent implementation of managePortSplitChild(DockingPort port). It is important to note that it is only necessary to assign a BorderManager to the root DefaultDockingPort. During nested docking operations, the DefaultDockingPort will automatically assign its current BorderManager to all child DockingPorts, thus preserving the border management behavior throughout the container hierarchy. |
||
|
|
||
|