In some situations I need to store contextinformation of the current
window.
The simplest solution is to store this information in the session.
But what happens, if the user opens the application concurrently in two
or more tabs? Worst case will be, that one window destroyes the context
of another.
A quite cumbersome method is, to store window specific information as
hidden fields inside the page. A more generic method would be very nice,
but that probably means to distinguish concurrent windows on the client.
In some situations I need to store contextinformation of the current
window.
The simplest solution is to store this information in the session.
But what happens, if the user opens the application concurrently in two
or more tabs? Worst case will be, that one window destroyes the context
of another.
A quite cumbersome method is, to store window specific information as
hidden fields inside the page. A more generic method would be very nice,
but that probably means to distinguish concurrent windows on the client.
How to identify a window on the client?
Don’t. If you need to store context information about each window, then
you’ve probably got a design problem that is making your app inflexible.
A properly designed Web application should not know or care if the user
has multiple windows open, IMHO.
What’s your use case? What are you trying to achieve, specifically, by
looking at window context?
The simplest case:
A paginated index that offers edit links, that return to the
current page of the index. The page number is stored in session.
Now the user opens the index in TAB 1, skips to page 5 and then
duplicates the tab creating TAB 2.
In TAB 2, he skips another 5 pages and clicks edit for one of the
entries - 10 is stored in the page attribute of session
Then he opens TAB 1 again (with index page 5) and clicks edit for some
entry - 5 is stored in the page attribute of session; the previous page
number 10 is lost.
Then he decides to go to TAB 2 and saves the object, expecting to
return to index page 10 and wondering, why he ends up in page 5.
A quite cumbersome solution is, to store the page number in a hidden
field, or in the save- and discard links of the edit form.
In the case, that the edit form can refer some other subpage, stack like
tracking can become a big deal.
The simplest case:
A paginated index that offers an edit link, that returns to the
current page of the index. The page number is stored in session.
Store the page parameter in the query string instead of the session.
Exactly! That way you won’t break the back button.
Right now, you’re using session data in such a way that index pages do
not have bookmarkable URLs. This is bad for many reasons, and is the
root cause of your proximate problem.
Rule of thumb: if you think you need to track your user’s clickstream in
the session to make your application work, then your design is
probably wrong.
(Note the emphasized phrase. If you want to track your user’s
clickstream for marketing or optimization purposes, that’s quite another
matter.)
No that’s no reinvention of the browser’s Back button, since usually the
rails show method redirects to the index. If it doesn’t know about the
page number, it returns to page 1.
Then you can use the back button twice or even more often, to return to
the index page, from where you started.
Store the page parameter in the query string instead of the session.
Thats, what I currently do. It is managable, if I have to return one
level to reach the index page, but I also have a situation, where two
levels are possible. The latter case very ugly to implement: you have to
track the page index in any link in level 1.
Is there really nothing in the DOM, that can be used to distinguish two
tabs in the client?
Store the page parameter in the query string instead of the session.
Thats, what I currently do. It is managable, if I have to return one
level to reach the index page, but I also have a situation, where two
levels are possible. The latter case very ugly to implement: you have to
track the page index in any link in level 1.
No. You don’t. Just give all your pages bookmarkable URLs, and rely on
the browser’s back button to do the right thing. Forget about trying to
do this in your app. The server shouldn’t care how the user has his
windows set up.
Is there really nothing in the DOM, that can be used to distinguish two
tabs in the client?
Not that I can think of. Why would there be? This is purely a
client-side concern and should be of no interest whatsoever to the
server.
Not that I can think of. Why would there be? This is purely a
client-side concern and should be of no interest whatsoever to the
server.
But it would be a possibility for the server to identify individual
tabs, if it could be submitted.
It is quite the same principle, than distinguishing two different
clients.
HTTP is stateless. The only way the server can distinguish different
clients is by the use of cookies – which are a stateful hack on top of
stateless HTTP.
For browsers to implement what you suggest would require a different
cookie store for different windows or tabs. I suppose there’s no theoretical obstacle to doing that, but I don’t think any browser
implementer ever actually has.
On Fri, Nov 12, 2010 at 11:25 AM, Marnen Laibow-Koser [email protected] wrote:
HTTP is stateless. The only way the server can distinguish different
clients is by the use of cookies – which are a stateful hack on top of
stateless HTTP.
Or by query string parameters (e.g. JSESSIONID) and url rewriting.
For browsers to implement what you suggest would require a different
cookie store for different windows or tabs.
Exactly.
But I think, I found something like page private cookies:
Use javascript_tag to inject an initialized string variable containing
the cookie data into the page.
Implement js functions to submit the cookie data via request parameter
This will even work, if there is no form in the document.
I don’t think that would work, unless you can keep track of the names of
your different cookies. But don’t ever do it; it’s a ridiculous hack.
Just make all your URLs bookmarkable, don’t break the Back button, and
the problem will go away.
I don’t think that would work, unless you can keep track of the names of
your different cookies.
That’s not necessary, since the data is contained in the page itself.
If you clone such a browser tab, the data is cloned too and will be
modified by subsequent requests without affecting the master copy of the
cloned tab.
But don’t ever do it; it’s a ridiculous hack.
Just make all your URLs bookmarkable,
OK, but take a look on the page source of an index containing a delete
link: There they inject a form onclick into the page, containing some
hidden field to submit data.
This trick could be used to post the page local cookie data, if there is
no form in the document; otherwise the problem can be solved by adding a
new hidden field on server side.
Rails is clever enough, to implement some generic code, that does this
fully transparent to the programmer.
don’t break the Back button, and the problem will go away.
This is not always possible - as pointed out above. It will work for
quite plane HTML pages, but not for more complex applications.
I’m only saying that per-window/per-tab storage is not out of the
question. It’s something that is coming standard in HTML5. Problem is
that most sites can’t reliably use this yet so this is really a moot
point in most situations.
Interesting. I didn’t realize HTML 5 storage was per window.
I’m only saying that per-window/per-tab storage is not out of the
question. It’s something that is coming standard in HTML5. Problem is
that most sites can’t reliably use this yet so this is really a moot
point in most situations.