Strategies for managing state on Rails

rubyonrails-talk
1

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

2

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

3

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