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.
No that's no reinvention of the browser's Back button, since usually the
rails update or 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.
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.)
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.
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 array containing the
cookie data into the page.
- Implement js functions to build submit the cookie data with requests
This will even work, if there is no form in the document.
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.
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.
