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? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. Now the user opens the index in TAB 1, skips to page 5 and then duplicates the tab (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. Then he decides to go to TAB 2 and stores the object, expecting to return to index page 10 and wondering, why he ends up in page 5. In the case, that the edit form can refer some other subpage, stack like tracking can become a big deal. A quite cumbersome solution is, to store the page number in a hidden field, or in the store link of the edit form. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Please quote when replying. Fritz Trapper wrote in post #960981:> 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.Why are you reinventing what the browser''s Back button already does? Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Sent from my iPhone -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
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. This is all but convenient. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Nov 12, 10:07 am, Fritz Trapper <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> 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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Tim Shaffer wrote in post #961029:> On Nov 12, 10:07am, Fritz Trapper <li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: >> 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.) Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Tim Shaffer wrote in post #961029:> 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? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Fritz Trapper wrote in post #961054:> Tim Shaffer wrote in post #961029: >> 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. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Marnen Laibow-Koser wrote in post #961055:> 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 the same principle, than distinguishing two different clients. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Fritz Trapper wrote in post #961059:> Marnen Laibow-Koser wrote in post #961055: >> 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. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Fri, Nov 12, 2010 at 11:25 AM, Marnen Laibow-Koser <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> 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. -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Marnen Laibow-Koser wrote in post #961071:> 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. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Fritz Trapper wrote in post #961082:> Marnen Laibow-Koser wrote in post #961071: >> 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. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Off topic: Marnen Laibow-Koser wrote in post #961071:> ... cookies -- which are a stateful hack on top of stateless HTTP.It''s not a hack, it is not implemented on top of HTTP and it doesn''t make HTTP stateful. It is simply a data exchange subprotocol within HTTP. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Marnen Laibow-Koser wrote in post #961085:> 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. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Fritz Trapper wrote in post #961091:> Marnen Laibow-Koser wrote in post #961085: >> 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.Modern browsers that are not completely ignorant have per-window storage on the client side: http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute 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. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Robert Walker wrote in post #961102:> Fritz Trapper wrote in post #961091: >> Marnen Laibow-Koser wrote in post #961085: >>> 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. > > Modern browsers that are not completely ignorant have per-window storage > on the client side: > > http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute > > 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. Best, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org Sent from my iPhone -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Robert Walker wrote in post #961102:> Modern browsers that are not completely ignorant have per-window storage > on the client side:But I guess, it''s still too early, to rely on ths feature. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Fritz Trapper wrote in post #961106:> Robert Walker wrote in post #961102: >> Modern browsers that are not completely ignorant have per-window storage >> on the client side: > > But I guess, it''s still too early, to rely on ths feature.As I said earlier... in all but a few cases it probably is too early: http://www.quirksmode.org/dom/html5.html -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
OK, so it''s no bad idea, to implement page local storage as described above. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Fritz Trapper wrote in post #961110:> OK, so it''s no bad idea, to implement page local storage as sketched > above.I certainly wouldn''t commit to saying that. All I''m saying is that it''s not a "left-field" idea to have per-window client-side storage. The HTML5 method seems to me to be the right way to manage it. But, unless you''re in a unique situation where you can require IE8+ (or any of the many other browsers that support sessionStorage) it''s too early it rely on it. There are still too many <=IE7 users out there to even consider this at present. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.