- From: Sebastian Hennebrueder <usenet@laliluna.de>
- Date: Thu, 04 Feb 2010 21:49:14 +0100
Hi all, About half a year ago I came up with an idea to add a unique window id as request header to each browser request. I published this initially on my website http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html About a week ago, I have stumbled upon the WebApps Working Group which sent me over to the whatwg user group. What is the idea about? The browser should generate an id unique per browser window and sent it as request header with every browser request. Request Header -------------- X-Window-Id: 279078917624897 This allows to identify which windows sent a request and helps to leverage the use of the HTTP session in multi page web application. I will describe this in more detail below. Why is it useful? Imagine you want to use accordion style menus (sample: JQuery UI - http://jqueryui.com/demos/accordion/) or menu groups like the one of JSF Richfaces (http://livedemo.exadel.com/richfaces-demo/richfaces/panelMenu.jsf?c=panelMenu&tab=usage). If you want to show the same menus or widgets opened after a page reload, then you need to memorize somehow what is opened or closed. We need to keep track of the application's state. Using the REQUEST We could store the information in the request. As a consequence, every form and link of our screen needs to include a list of opened menus/widgets. This could be achieved by manipulating all links and forms using JavaScript. The advantage is that it works with multiple windows and does not require a user session. The disadvantage is that it pollutes the request and enlarges the data sent by every request. In an application with a lot of stateful information it could be impossible to follow this approach. Using the SESSION The other solution is to store the state in the users session. Every time a menu/widget is opened, we send an Ajax request to keep track of opened menus. The downside of session usage is that it is impossible to use multiple windows in the browser because they would overwrite other window's state (opened menus). This is because a user session is normally stored as browser cookie and cookies are merged into a single space for all browser windows (new exception: secure browser windows) Using the Window id Having a window id, we can save the list of opened menus/widgets per window in the user session. We split up the user session in slices. In pseudocode it looks like this: id = request['x-window-id'] context = session[id] menus = context['menus'] It is quite interesting that HTML 5 solves the problem for the client side of JavaScript applications. The sessionStorage allows fine grained controll if data is seen by all windows or just by the current. The problem only persists for client ? server applications. Another use case are dialogs or conversations which span multiple pages. We could think of a complex dialog to edit an item or the checkout process of a shop application. With a windows id, we know that the complex dialog was started in a window and that the user is now visiting another area. This allows to clean up the session area for this window. I created a plugin for Firefox which adds the window-id to a request. You can use my ruby based sample application to test the be behaviour. You can find the original article, the plugin etc in my blog. http://www.laliluna.de/blog/categories/ideas/ I am looking forward to your feedback. -- Best Regards / Viele Gr??e Sebastian Hennebrueder ----- Software Developer and Trainer for Hibernate / Java Persistence http://www.laliluna.de
Received on Thursday, 4 February 2010 12:49:14 UTC