Tim Hutt schrieb:
On 4 February 2010 20:49, Sebastian Hennebrueder <use...@laliluna.de> wrote:
What is the idea about?
I think "Web Storage" does what you want and is already implemented
(apparently even in IE). The description from the spec:
"This specification introduces two related mechanisms, similar to HTTP
session cookies, for storing structured data on the client side.
The first is designed for scenarios where the user is carrying out a
single transaction, but could be carrying out multiple transactions in
different windows at the same time.
Cookies don't really handle this case well. For example, a user could
be buying plane tickets in two different windows, using the same site.
If the site used cookies to keep track of which ticket the user was
buying, then as the user clicked from page to page in both windows,
the ticket currently being purchased would "leak" from one window to
the other, potentially causing the user to buy two tickets for the
same flight without really noticing.
To address this, this specification introduces the sessionStorage IDL
attribute. Sites can add data to the session storage, and it will be
accessible to any page from the same site opened in that window.
For example, a page could have a checkbox that the user ticks to
indicate that he wants insurance:
<label>
<input type="checkbox" onchange="sessionStorage.insurance = checked">
I want insurance on this trip.
</label>
A later page could then check, from script, whether the user had
checked the checkbox or not:
if (sessionStorage.insurance) { ... }
If the user had multiple windows opened on the site, each one would
have its own individual copy of the session storage object."
Hi Tim,
thank you for the feedback. I hope that I see your point correctly. You
are right, that for JavaScript based applications this can easily be
solved with a sessionStorage. All technologies around GoogleWebToolkit,
Dojo, Echo etc which hold the state in the client and make use of a
stateless server side application can use the session storage to
distinguish browser windows.
But there are a lot of web technologies which hold the state on the
server using the browser session. Technologies like Ruby on Rails,
JavaServerFaces, Wicket, Struts, Tapestry to name a couple of them.
Those technologies can not make a simple use of the session storage.
They are only aware of the browser session which is a common space of
all browser windows. The windows id let them split the session in a per
browser window scope.
Originally, when playing with the window id concept, I simulated a
window id by storing it in a session storage and adding it with the help
of JavaScript as parameter to all links and as hidden field to all
forms. It works to some extend but it pollutes the URL and is likely to
cause problems with bookmarking and there is a use case where it fails.
If you open a link in a new windows. In that case the first request is
sending the wrong windows id.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
