Persistent storage: guts + docking-frames

Byte-Welt - Projekte / Projects DockingFrames
1

Beni:

in the guiedes you say:

“The client is responsible to store the contents of any single-dockable.”

in my case I have 2 frameworks: guts and docking-frames,
which both provide and need persistence;

quiestion:

  1. what is proper demarcation/separation of what is stored by docking-frames, and what is not?

in other, words, in dockable you have a pane:


public class DefaultDockable extends AbstractDockable {
    /** the content pane */
    private JPanel pane = new JPanel( new BorderLayout() );

so:

  1. does docking-frames map CLocation to this pane? or am I responcible for both pane and below?

or, I can re-phrase the question like this:

  1. how can I properly iterate over all the “stuff” that “grows” from CControl,
    and find only those swing components I am responcible to persist?

finally:

  1. should I pay attention only to things inside <? extends AbstractDockable>
    or are there some other components inside, say <? extends AbstractDockStation>
    which I am also responsible?

thank you;

Andrei

2

DockingFrames stores only the unique identifier of the SingleCDockable and all available location information.

You need to store:

  • Any properties set with methods like “setMinimizeable”, “setCloseable”, “setTitleText”, …
  • In your example anything that is shown on “pane”.

You don’t need to store:

  • anything related with the current location: not the parent, not the extended-state
  • anything related with the history of locations

You can:

  • ask the CControl for all SingleCDockables (control.getRegister().getSingleDockables()) to iterate through all the dockables you created.
  • use the “ApplicationResourceManager” (control.getResources()) to store any data together with layout information of DF.

You must:

  • tell CControl which dockables to expect before loading a layout
    • by adding CDocakbles
    • by adding SingleCDockableBackupFactory s
    • or implement a MissingCDockableStrategy (control.setMissingStrategy) and add the dockables later
3

got it; making a test now;

4

curious:

why do you call multiple:

MultipleCDockableFactory

buy for single:

SingleCDockableBackupFactory

it seems in my case I will generate both single and multiple
from factories always (regardless whether first run or restore/next run),

so whats the deal with „backup“? :slight_smile:

5

History. In the younger versions there was no factory for SingleCDockables. It was first introduced as kind of a backup factory, and it kept that name.

6

got it;

do you feel at some point (v 1.1.0 ?) you will have to bite the bullet and do renames / break interfaces?

7

I fear yes. It would not be the first time, the framework was never 100% backwards compatible (although I wished it would).

As I’m getting a bit better organized I intend to do such changes more slowly: e.g. in version 1.1.0 an interface will be deprecated and empty, its content moved to the new replacing interface (the old one extends the new one, to keep old code running). And in 1.1.1 the old interface is removed completely. That is also the way I’ll exchange some of the method names.

8

cool; then I’ll be ready;

9

another curiousity:

when I run docking-frames-demo-layouts, then make bunch of layouts, save them
and then keep doing restore on one of them repeadedly,
the dockable that gets the focus as a result changes all the time
and seems to be random - which one it its;

just curious how did you manage to get this in a deterministic app? :slight_smile:

10

Hm, that is a good question. At least I can confirm that the focused Dockable is not stored anywhere. My best bet is, that the last Dockable that was moved around gets the focus.