View Full Version : Storing Grid State per User and storing serverside - EXT GWT

25 Oct 2012, 12:42 PM
So I have been looking around the interwebs on how to store an EXT paging grid state on my server so that when users login back in their grid it is how they saved it.

I found this http://www.sencha.com/forum/showthread.php?64688-How-can-i-save-Grid-state-using-GXT but it is an old and dead thread.
What I have right now is:

grid.getState() returns a map of all col sizes, sorts, and hidden fields.
here is an example dumped to string:

{offset=0, limit=25, widthfieldname1=161, widthfield2=110, hiddenfield3=true }

I could store these key/values in a simple table with fields (username, key, value) and recreate this map and pass it to the front end.
So here is my question:

Does anyone have a code example of a full implementation of storing, retrieving and apply a grid state for EXT 2.4?

If not. How would I go about implementing one? I am confident i could store the state map in the database or XML. I am lost on how to apply this to a new session. How do i apply this state map to a new grid?

Colin Alworth
3 Nov 2012, 7:46 AM
The state details should be passed to and from the client when it starts up, to a custom subclass of com.extjs.gxt.ui.client.state.Provider. Take a look at CookieProvider as an example of how this can be done for simple cookies.

By creating a Provider, you can let the global StateManager instance actually control this logic, and you can just poll that one object for changes, and just save at the one time, for all state-enabled components in the application. Additionally, by providing state to the manager via your custom Provider, you can ensure that anything that needs state will be able to consistently read it from this.

My advice would be to start with a CookieProvider to make sure your state-consuming widgets all behave correctly. Then, when you are sure that they are saving in the simple case of local cookies, build a custom provider, and ensure that it is both sending data to the server, and loading it on page startup. Remember that the provider needs to have all details loaded before those widgets can begin.

StateManager is already wired into the Component and all subclasses through the initState() method, which reads from the global StateManager and reads out those maps.

If you don't want to use the StateManager and the Provider api to build your own, you'll need to turn those JSON strings back into maps again, and copy those values into the getState() returned map, and invoke the protected applyState method. This is protected to keep this logic internal, but you can use JSNI to invoke it, or subclass the widget you are building this into. It is up to each widget to correctly implement applyState to restore the new state, or listen to the StateRestore method.