views:

1404

answers:

3

The users of my web application may have more than one browser window open and pointed to the same page. I would like the state of certain in things in the page (loaded via ajax) to be retained across postbacks. I can either store in a cookie or on my server. Either way, I can't think of how I can distinguish each window.

For example, say user Bob has two browser windows open to the ListOfSomething page. Each list has a LoadedPageNumber attribute which I need to persist. Otherwise users always end up on page 1 when they refresh. Bob might have loaded browser window 1 and pointed it to page 5 and then loaded browser window 2 and pointed it to page 14. If I just store the attribute based on session id, Bob will get page 14 in window 1 if he refreshes it.

Note that my state variables are actually much more complex than this simple example and my inability to persist them could lead to big problems (weaknesses in my app).

I need some kind of browser window id or something. It of course needs to be a cross-browser solution (IE6+, Wekbit?+, FF2+)

Any ideas?

Thanks

Note on relevance: Keep in mind that this is useful also for the case where you're mixing older forms based pages with newer AJAX enabled items. Sometimes you need to postback the forms and you don't want to loose some client side state values.

+1  A: 

you could set your own window name, the exact syntax escapes me right now, but you can use the current time and session id to create a unique id on window load, then use that id

This would be done the same way you set a name in the javascript window.open() function, (but you can do it to self, instead of new window)

googling shows:

self.window.name = myclass.getUniqueWindowId( thisSession );

UPDATE: regarding your need to save this from refresh to refresh, i did some tests and it looks to save it from refresh to refresh. Using Firefox 3, on inital load, the window name is blank, and pressing CTRL+R over and over, and the window name was populated. i then commented out the setting the name code and reloaded and it still retained the name.

<script type="text/javascript">

    alert( self.window.name );

    self.window.name = "blah";

</script>
Roy Rico
Yup, this is great. I'm already using jQuery and I found a pluging that does this exactly:http://code.google.com/p/jquery-session/
Mr Grieves
A: 

What about having your server randomly generate an ID and have that stored in the page (some javascript variable) when it's served? Then just include that ID in the ajax request. It wont' help on a browser refresh, but as long as the user leaves that page in place (and just lets the ajax stuff do its thing) it should work fine.

Herms
My problem is the browser refresh. That's the objective of the question.
Mr Grieves
A: 

Regarding jquery-session, that link to google code is no longer publicly available.

However, I wrote something for my own purposes, and packaged it as a standalone library. It is available for download as backtrack.js. There is plenty of documentation inside the file (in fact it's more documentation than code).

The specific problem I wanted to solve was with a web-app with several pairs of parent(search)/child(detail) pages. The parent/search screen has a search context stored in hash args of the URL. The child screen has a button back to the parent search screen. The goal is to easily restore the hash args whenever returning to the parent search screen.

The challenge is that the user might have the same screen open in multiple tabs. I wanted a solution where each window/tab maintained its own context. The attached file is the API I used to do it. It works for applications where your screens store their state in the hash part of the URL. The library will maintain a trail of pages and associated hash args within each tab/window. A single function call will save/restore as required.

To use it, first ensure that your pages store their state in hash args.

Then simply include "backtrack.js", and in the parent screen shortly after page load (and before you examine any hash args), call:

backtrackApply();    // Store or Restore hash args as appropriate.

Then wherever you change your hash args within the parent screen (via location.replace), call:

backtrackApply(true);    // Store new hash args.

Note that the hash args are restored to location.hash. However the API does not change document.url.

Full documentation from the header of the file is on a posting on my blog.

the.jxc