Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can wcDocker "just" restore the positions/dims of panels without re-instantiation? #105

Open
lomotelsch opened this issue Mar 22, 2016 · 6 comments
Assignees
Labels
Milestone

Comments

@lomotelsch
Copy link

Saving/restoring the panels using api-functions saveLayout() and restoreLayout() will destroy all panels first and re-instantiate them afterwards.

The problem with this is, that all panel-content (data) and all changes made to the content (scrolling down a list, checking a checkbox) must be re-initialized and re-set after restoring the panel-layout using restoreLayout().
For the content, which comes from the backend, this is ok in general - we can restore this.
But the other (non-db related) changes applied to the content (scrolling down a list, applying a filter to a table, ..) get lost.

In our case we have a fixed number of different panels with different content.
There are no dynamically created panels nor can the panels be closed.
The panels are collapsible, moveable and can float.

So do you have a clou howto just save/restore the positions and dimension of the panels without re-instantiating them?
I mean, can I restore the positions/sizes of panels just using your api like panel.collapse(), panel.setSize() i.e.?
Do I get all informations from the panels using your API to restore them (position, size, order)?

Would be helpfull to get a tendence in any direction from you..

Thanks, Sebastian

@lomotelsch lomotelsch changed the title Can wcDocker "just" restore the positions of panels? Can wcDocker "just" restore the positions/dims of panels without re-instantiation? Mar 22, 2016
@Lochemage
Copy link
Contributor

@lomotelsch

There are two ways I can think of to solve this problem:

1: Since all of your panels can not be moved or edited, you could probably get away with setting all your panels to persistent (see http://docker.api.webcabin.org/module-wcDocker.html#~registerOptions, the isPersistent option). This will make it so even if the panels are removed, they are technically never removed from memory and will just be re-shown when a new panel is added (eg via the restore layout).

2: You can leverage the save/restore layout event handlers to save and restore your own custom data (see http://docker.api.webcabin.org/module-wcDocker.html#toc4 under the SAVE_LAYOUT and RESTORE_LAYOUT event types). When the layout is being saved, you would remember what properties and filters were enabled, then when the layout is restored you can restore those options again.

@Lochemage
Copy link
Contributor

@lomotelsch

For the second one, I actually have a tutorial here: http://docker.api.webcabin.org/tutorial-2.0-tips-and-tricks.html#toc4

@lomotelsch
Copy link
Author

@Lochemage

1: Since all of your panels can not be moved or edited, you could probably get away with setting all your panels to persistent

nice, I will look into this

@lomotelsch
Copy link
Author

@Lochemage
I looked into the isPersistent option.
This works nicely when you close and recreate a panel manually, since the isPersistent-option is enabled, you just move the panel into a hidden container - all bound events and data()-properties are kept.
But when you use wcDocker.restore() to restore the previously saved layout, all panel-content gets removed using the jQuery.remove()-method, which also removes events and data-properties:
https://github.com/WebCabin/wcDocker/blob/master/Code/layout.js#L402

Switching to jQuery.detach() when isPersistent is set would fix this

In my scenario, wcDocker is wrapped by angular-directives, which use the data-properties heavily - so this will actually break by restoring the layout.

@Lochemage
Copy link
Contributor

@lomotelsch

Hmm, you're right. I'll have to fix this, although I don't know when I'll have a chance to work on it.

@Lochemage Lochemage added the bug label Apr 6, 2016
@Lochemage Lochemage added this to the 3.0.0 milestone Apr 6, 2016
@Lochemage Lochemage self-assigned this Apr 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants
@Lochemage @lomotelsch and others