saveState - what does it do

[eugenparaschiv]

I've been looking at ways to store some visual stat of my application on the server, so that the visual preferences of the users are not lost when the user logs out.
My question is: what does the saveState() method from Component do? Is this a way to store visual preferences on the server, as state? If so, how does it work?
The way I did this was rather convoluted (I used a serializable mirror hierarchy of classes on the server...the details are not really important), and all the while I was thinking that there must be a better way to do this.

Thanks.

[gslender]

it stores the map of state values into a cookie

various widgets use this to store their current state (ie collapse panels in border layout)

cheers,
grant

[eugenparaschiv]

Very cool, but can you elaborate a little...as I see it now:
- the state is basically an empty map, and at this point, is used only by BorderLayout
- this map can store some state related mappings, but not really store the nuts and bolts of a component; for example if I modify the width of a panel or if I hide the header, then when the application is loaded again, I would want something like this:
panel.setWidth( state.getWidth()); or panel.setWidth(state.get("width"))
and
panel.setHeaderVisible(state.getHeaderVisible()) or panel.setHeaderVisible(state.get("headerVisible"))
with the state coming from the server

Is something like this possible using this state map?

- and the last thing: does all of this state just go away when I delete the cookie? Or can I really store it on the server side somehow?
Thanks.
Eugen

[gslender]

what you want is possible, just not the way you have described it - the widgets would need to be overridden to build in that "stateness" you describe (or manually implement whenever used) - similar to how borderlayout does it.

and as the component uses StateManager, you can effectively plug in your own stateprovider and store things in any persistent way you wish.

[eugenparaschiv]

Yeah, I thought this is the way to go. I still have some questions though. For instance:
- is this state functionality more extensively used in the EXT JS API? Because if it is, then there's a good chance for it to be implemented here sooner or later I think. It just seems a waste to include this so low in the hierarchy (in Component) and then not use it.
- the idea of plugging in the state functionality seems right, but because things are kept in a map, you would have to do this not only by hand but also very low level; what I mean is this:
say you decide that some component has a few parameters that have to be remembered and thus stored on the server; out of all the parameters that could be stored, the user only modifies a few (and so stores them in the map); but when actually retrieving these parameters from the map, you cannot now which ones the user saved, so you have to try to retrieve them all, test for null and then set them on the widget, which is a rather low level way to do things; would there be any alternative to this whole approach?

- then, my last question: would this all be for nothing if the user deletes the cookie?

Thanks for your answers.
Cheers.

[bgmoon]

I've also been looking at how the StateManager is intended to be used and what level of support it has. Trolling through the source it appears that the StateManager is basically complete but its usage by the widgets is just a placeholder for now.

To use the StateManager, you'd get an instance of it with StateManager.get(), then you could either instance a "CookieProvider" if you want to store state in cookies or you could sub-class Provider to roll your own provider (for example server side storage.) You'd then bind the StateManager to the Provider. You'd do this before instantiating any widgets. All that stuff appears to be there and done.

As for exploiting the StateManager, it appears that only a single class "BorderLayout" usese it. It first appears in "Container", where everything is implemented with the exception of the empty "applyState" method -- unfortunately that method is 'protected' and so can only be sub-classed within the same package.

[eugenparaschiv]

One obvious and somewhat non application-specific place where this kind of functionality could be used is a stateful portal. This has already been widely discussed on the EXT JS forums, and would be great to see here as well, perhaps even as part of the official functionality, instead of a user addition:
http://extjs.com/forum/showthread.ph...tateful+portal

As for the state functionality, I think you are right, it does seem like the back end stuff is finished and just not used. Writing my own provider for server-side storage is all well and good, but I admit I would like to let this come up as official functionality soon instead of doing it myself and then having to let it go down the line because the official stuff arrived. Anyways, this is doable, but how can I make other, standard widgets use it, when these widgets simply ignore the state functionality altogether? I don't like the idea of branching the GXT code, especially not for the whole API.

[bgmoon]

What I've done is to create a set of 'stock' listeners that I can attach to widgets that I want to be stateful. I can use the same listeners for all of the various widgets and I don't have to change the code in the widget itself to do it. I set up the StateManager in the 'entry point' early, then I create my listeners and put references to them into the Registry. Then in my View's, I get a reference to the listeners and attach them to various widgets as I construct them. When the widget first gets rendered, my listener gets called, I recall state information and then apply it on a generic basis to the 'widget componet' that the event was called on. I save all the state information in a HashMap of HashMap's where the outter hashmap uses the object ID of the 'view' as a key to get a hashmap of key/value pairs for any given widget. As the widget is re-configured, my listeners get those events and then persist the changes using calls to the StateManager.

Its not idea, but its doable. I've seen worse.

[glidealong]

what you want is possible, just not the way you have described it - the widgets would need to be overridden to build in that "stateness" you describe (or manually implement whenever used) - similar to how borderlayout does it.

and as the component uses StateManager, you can effectively plug in your own stateprovider and store things in any persistent way you wish.

It would be really helpful if you could provide a simple implementation to have the state manager to store and restore the state of a toggle button.

Sorry for my ignorance, i am kind of going back and forth regarding the feature.

Thanks in advance,

Best Regards,
Hafiz

[glidealong]

It would be really helpful if you could provide a simple implementation to have the state manager to store and restore the state of a toggle button.

Thought I will answer my question

public class ToggleButton extends
        com.extjs.gxt.ui.client.widget.button.ToggleButton
{
    
    public ToggleButton()
    {
        super();        
        stateId = "toggler";
        if(StateManager.get().get("toggler")!=null)
        {
            //Window.alert(StateManager.get().get("toggler").toString());
            Map<String,Object> st = (Map<String, Object>) StateManager.get().get("toggler");
            this.toggle(st.get("toggle").equals(true));
        }
        addSelectionListener(new SelectionListener<ComponentEvent>(){

            @Override
            public void componentSelected(ComponentEvent ce)
            {
                Map<String, Object> state = ce.component.getState();                
                state.put("toggle", isPressed());
                saveState();
                
                
            }});
        
        setText("Remember Me");
    }

It works!!!!