1. #1
    Ext User
    Join Date
    Jul 2008
    Posts
    202
    Vote Rating
    0
    eugenparaschiv is on a distinguished road

      0  

    Default saveState - what does it do

    saveState - what does it do


    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.

  2. #2
    Ext GWT Premium Member gslender's Avatar
    Join Date
    Mar 2008
    Location
    Brisbane, Australia
    Posts
    1,572
    Vote Rating
    4
    gslender is on a distinguished road

      0  

    Default


    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

  3. #3
    Ext User
    Join Date
    Jul 2008
    Posts
    202
    Vote Rating
    0
    eugenparaschiv is on a distinguished road

      0  

    Default


    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

  4. #4
    Ext GWT Premium Member gslender's Avatar
    Join Date
    Mar 2008
    Location
    Brisbane, Australia
    Posts
    1,572
    Vote Rating
    4
    gslender is on a distinguished road

      0  

    Default


    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.

  5. #5
    Ext User
    Join Date
    Jul 2008
    Posts
    202
    Vote Rating
    0
    eugenparaschiv is on a distinguished road

      0  

    Default


    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.

  6. #6
    Ext User
    Join Date
    Sep 2008
    Location
    North Carolina
    Posts
    7
    Vote Rating
    0
    bgmoon is on a distinguished road

      0  

    Default Looking into the same issue

    Looking into the same issue


    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.

  7. #7
    Ext User
    Join Date
    Jul 2008
    Posts
    202
    Vote Rating
    0
    eugenparaschiv is on a distinguished road

      0  

    Default


    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.

  8. #8
    Ext User
    Join Date
    Sep 2008
    Location
    North Carolina
    Posts
    7
    Vote Rating
    0
    bgmoon is on a distinguished road

      0  

    Default One suggestion/alternative to branching

    One suggestion/alternative to branching


    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.

  9. #9
    Ext User
    Join Date
    Aug 2008
    Posts
    40
    Vote Rating
    0
    glidealong is on a distinguished road

      0  

    Question


    Quote Originally Posted by gslender View Post
    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

  10. #10
    Ext User
    Join Date
    Aug 2008
    Posts
    40
    Vote Rating
    0
    glidealong is on a distinguished road

      0  

    Cool


    Quote Originally Posted by glidealong View Post
    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

    Code:
    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!!!!