W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Window id - an idea to make multi page web application easier

From: Sebastian Hennebrueder <usenet@laliluna.de>
Date: Mon, 18 Jan 2010 16:54:12 +0100
Message-ID: <4B548424.50105@laliluna.de>
To: public-webapps@w3.org
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

Now, I have stumbled upon the WebApps Working Group and would like to 
introduce this here as well.

What is it?
The browser should generate a unique id 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 solves a lot of 
common problems in web application. I will describe them 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). 
Another use case is an application having dialogs like the Gimp image 
tool or Photoshop which have a number of widgets opened (see attached 
screenshot).

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 concept is called sessionStorage. 
The problem only persists for client – server applications.

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
-----
http://www.laliluna.de






gimp-screenshot.png
(image/png attachment: gimp-screenshot.png)

Received on Tuesday, 19 January 2010 00:03:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT