How not to pass cookies in an ExtJS HTTPRequest

I have an application using ExtJS on the front end and TurboGears on the server. I am now started to add cookies to handle customisation front side using the CookieProvider state manager. This is cool but the cookies are passed on every call and these cookies are sizable. I have concerns about the performance hit.

Long and开发者_运维百科 short, is there a way I can block certain cookies from being sent on calls to the server?

• Dave

If you know your users are using modern browsers, you can use HTML 5 Local Storage instead of cookies.

This is exactly what it's meant for - storing data such as customization locally on the client.

It frees you from the issues you have with cookies like getting sent to the server and a smaller size limit.

To make our ExtJS-based application work without cookies enabled (which means that each request from the Client written in JS and using AJAX-requests for communication with Java-based server will create a new Session-ID and therefore can not be assigned to any specific session by the server), I figured out the very simple method of overwriting the AJAX-method of ExtJS and adding the session-ID to each request solves this problem. I got the idea from another thread where it was shown how to overwrite Ext.Ajax to add a certain parameter to each call and am using this way to add the session-ID with appending ";jsessionid=' to each URL-parameter.

I believe your last response is correct...but you should share the answer instead of glazing over it...I believe you are using the params in this manner, if not this is another way I believe of accomplishing what you are trying to do.

Ext.Ajax.Request({
    url: 'path/to/file.htm',
    params: {
        jsessionid:  Ext.util.Cookies.get('jsessionid')
    },
    success: function(result, request) {
        // Callback function for successful request
    }
});

Here's a rundown of what I ended up implementing: All customisations are stored in a database. When a screen is being navigated to, I read the screen customisations for the current user and use it to initialise a simple memory based state provider in the init_component routine. The state provider listens for appropriate events and updates the in-memory state. The UI has a Preferences menu with and Save/Reset options. The save option saves the memory state to the server. Reset deletes the state from the database and rebuilds the screen with the default settings. This seems to work well.

FYI: other gotchas I found:

• grids don't have an event for filter change
• combo boxes (amongst others) don't have code to save state, you have to write your own.
• the state from grids is profligate (the original problem)

I implement one state setting per stateful control per screen, usually there is only one grid but one screen has a combo plus a grid. It probably would have been better to bundle them but lack of time...