Strategies for managing state on Rails

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

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

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