This may be obvious (either obviously simple or, on the other hand, obviously a very hard problem), but I''m working on my first non- trivial Rails app (well, web app in general for that matter) and I''m running time and time again into the problem of managing client state. On several pages, my app has some state that needs to be set at the page level, but used to render the page and be used when AJAX code re- renders parts of page (for instance, the app allows some fields to manipulated with AJAX). At first, I tried passing all the state through the links (i.e. embedded the state in the URL), but this seemed both inefficient (I have some reasonably large objects and we could only pass IDs through the links, so I had to hit the DB again each time) and tricky to manage - I found myself passing tons of state through links and it was hard to manage it all. So, I tried keeping it all on the server. It was efficient, much easier to manage (I could set some state at the controller level, and access it anywhere). Unfortunately, it has created some nasty bugs (since I have to track down what weird state the app is in) and doesn''t work when a user users the page in multiple windows/tabs (since the state gets all mixed up between instances). I''ve been reading up on REST as well as continuation-based servers (which, from my limited understanding and very roughly speaking, very intelligently store user state on the server), which leads me to believe I should try one of the following strategies: 1. Try to be as RESTful as possible and ditch all server-side state. I think the best approach would be to have some object that encapsulates all the data that needs to be encoded in the URLs and has helpers to write URLs for me (i.e has specialized versions of link_to, etc). 2. Keep the server-side state, but make it a lot smarter - able to handle multiple tabs/windows from the same user simultaneously How have others handed storing user state in their apps? Are there strategies/gems/plugins/design patterns that people have used to successfully implement option 1 or 2 above? Thanks, Ben --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 7, 2008 6:25 PM, bhbrinckerhoff <bhbrinckerhoff-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > This may be obvious (either obviously simple or, on the other hand, > obviously a very hard problem), but I''m working on my first non- > trivial Rails app (well, web app in general for that matter) and I''m > running time and time again into the problem of managing client > state.Read up on sessions. A session follows the user. You can have it on the server in the database, on the server in a file or in the client''s browser as a cookie. All have their plus points and drawbacks. The cookie method is the easiest one to set up on Rails 2.0. Then, for each user, you set a flag in the session like "logged_in true" or whatever and then you can pass instance variables down into the view. Simple example: In your login controller: class SessionsController < ActionController def create session[:name] = "Mikel" session[:logged_in] = true end end You could then directly reference the session in your view, like this: Hello <%= session[:name] %> <% if session[:logged_in] -%> do some stuff <% else -%> do some other stuff <% end -%> Although, doing it like this is bad form IMHO. You shouldn''t have views accessing the session, I tend to make methods in my application controller like so: def logged_in? session[:logged_in] end def current_user_name session[:name] end And then when I call the view, I pass it the session params I think best like so: def show @name = current_user_name @logged_in = logged_in? end This un couples the session from the view and allows you to change things like, how do you determine if someone is logged in? Ryan Bates has some good stuff on this at railscasts.com I think. Regards Mikel --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Sorry, my fault - I should have explained that when I said I "I tried keeping it all on the server", I was using sessions as the mechanism for storing state on the server. Sessions are great for per-user data, but unfortunately they don''t work so well for per-page data. Here''s an example - my application shows lists of items, and the user can use AJAX so quickly move back and forth from ''pages'' of results (all rendered by AJAX within the same HTML page). I tried keeping the current page number in the session, but that doesn''t work very well when the user has two tabs open in the application (the state is in conflict between tabs, because it''s all the same user). So, option 2 in my original post would amount to making data stored in sessions much smarter, but I''m not sure if that''s a good idea (or if there is an existing gem/plugin to do this for me). Thanks, Ben On Feb 7, 1:13 am, "Mikel Lindsaar" <raasd...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Feb 7, 2008 6:25 PM, bhbrinckerhoff <bhbrinckerh...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > This may be obvious (either obviously simple or, on the other hand, > > obviously a very hard problem), but I''m working on my first non- > > trivial Rails app (well, web app in general for that matter) and I''m > > running time and time again into the problem of managing client > > state. > > Read up on sessions. > > A session follows the user. You can have it on the server in the > database, on the server in a file or in the client''s browser as a > cookie. All have their plus points and drawbacks. The cookie method > is the easiest one to set up on Rails 2.0. > > Then, for each user, you set a flag in the session like "logged_in > true" or whatever and then you can pass instance variables down into > the view. > > Simple example: > > In your login controller: > > class SessionsController < ActionController > def create > session[:name] = "Mikel" > session[:logged_in] = true > end > end > > You could then directly reference the session in your view, like this: > > Hello <%= session[:name] %> > <% if session[:logged_in] -%> > do some stuff > <% else -%> > do some other stuff > <% end -%> > > Although, doing it like this is bad form IMHO. You shouldn''t have > views accessing the session, I tend to make methods in my application > controller like so: > > def logged_in? > session[:logged_in] > end > > def current_user_name > session[:name] > end > > And then when I call the view, I pass it the session params I think > best like so: > > def show > @name = current_user_name > @logged_in = logged_in? > end > > This un couples the session from the view and allows you to change > things like, how do you determine if someone is logged in? > > Ryan Bates has some good stuff on this at railscasts.com I think. > > Regards > > Mikel--~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---