Persisting old dock layout.

[Adrian]

I want to write a dashboard page which will be initially built dynamically but then stored in the db for re-use so that the users can then move the docks around as they wish.  However, what happens when we remove a referenced ascx control?   The stored serialised layout would contain the details of an ascx that doesn't exist anymore.. does it just ignore it, or does it fail to load the whole dock layout?

[Slav]

Hi Adrian,

The built-in layout persistence of RadDock does not include the content of the dock controls. If the referenced ascx control that you mentioned is loaded in a dock, the serialized dock state will not contain it by default so there should be no errors.

This, however, means that you need to store the state of the content of the docks separately, otherwise the web user controls you are loading in the docks will not be persisted. For example, the following demo of RadDock has loading of user controls in the docks and the name of the loaded user control is kept in the Tag property of RadDock: http://demos.telerik.com/aspnet-ajax/dock/examples/myportal/defaultcs.aspx When a dock is recreated, the correct user control is loaded via the information in the Tag property.

If the example in the demo does not meet your requirements or if I misunderstood you, please describe your scenario in greater detail. Are you using the same approach as the one in the demo for persisting the dock state in your project? Is the referenced ascx control loaded in a dock or somewhere else?

Regards,
Slav
Telerik

 

 

[terrysmith]

I have a related question to this thread. I am also trying to persist a dashboard page to a database so that users can add/remove/reposition docks. Each dock will have a user control with functionality.

Slav, the My Portal example that you mentioned as well as this one (http://www.telerik.com/forums/raddocklayout-radzones-raddock-user-control-ajax-in-code-behi​nd) use LoadDockLayout and SaveDockLayout. However, the documentation for built-in dock state persistence (http://www.telerik.com/help/aspnet-ajax/dock-built-in-state-persistence.html) says that those event handlers are no longer necessary when using the new storage provider interface. 

In my own tests I'm not getting dynamically-added controls to repopulate on the page using just the LayoutPersistenceRepositoryType  of Custom. Do I need to instead persist a list of DockStates like the first two examples and also persist any user control settings? When is the built-in persistence useful and when is it not?

Thank you,

Terry

[Slav]

Hi Terry,

The built-in dock state persistence that is explained in the help article you linked and demonstrated in the following demo is designed to be used with declaratively created RadDock controls and not with programmatically created ones: http://demos.telerik.com/aspnet-ajax/dock/examples/builtindockstatepersistence/defaultcs.aspx. It uses layout storage providers that handle the persistence of the dock state and not their recreation if they are initially created on the server.

That being said, if your scenario includes dynamic creation of docks, the approach that is shown in the My Portal demo will be more appropriate.

Regards,
Slav
Telerik