Handling Cookies and DHTML Effects with Ruby on Rails
(Page 1 of 4 )
In this fourth article of a six-part series covering web development and Ruby on Rails, you'll learn how to extract code into helper functions, add DHTML effects, and more. This article is excerpted from chapter 15 of the
Ruby Cookbook, written by Lucas Carlson and Leonard Richardson (O'Reilly, 2006; ISBN: 0596523696). Copyright © 2006 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.
15.12 Setting and Retrieving Cookies
Problem
You want to set a cookie from within Rails.
Solution
Recall from Recipe 15.11 that all Rails controllers, views, helpers, and mailers have access to a method called sessions that returns a hash of the current client's session information. Your controllers, helpers, and mailers (but not your views) also have access to a method called cookies, which returns a hash of the current clients HTTP cookies.
To set a cookie for a user, simply set a key/value pair in that hash. For example, to keep track of how many pages a visitor has looked at, you might set a "visits" cookie:
class ApplicationController < ActionController::Base
before_filter :count_visits
private
def count_visits
value = (cookies[:visits] || '0').to_i
cookies[:visits] = (value + 1).to_s
@visits = cookies[:visits]
end
end
The call to before_filter tells Rails to run this method before calling any action method. The private declaration makes sure that Rails doesn't think the count_visits method is itself an action method that the public can view.
Since cookies are not directly available to views, count_visits makes the value of the :visits cookie available as the instance variable @visits. This variable can be accessed from a view:
<!-- index.rhtml -->
You've visited this website's pages <%= @visits %> time(s).
HTTP cookie values can only be strings. Rails can automatically convert some values to strings, but it's safest to store only string values in cookies. If you need to store objects that can't easily be converted to and from strings, you should probably store them in the session hash instead.
Discussion
There may be times when you want more control over your cookies. For instance, Rails cookies expire by default when the user closes their browser session. If you want to change the browser expiration time, you can give cookies a hash that contains an :expires key and a time to expire the cookie. The following cookie will expire after one hour:*
cookies[:user_id] = { :value => '123', :expires => Time.now + 1.hour}
Here are some other options for a cookie hash passed into cookies.
The domain to which this cookie applies:
:domain
The URL path to which this cookie applies (by default, the cookie applies to the entire domain: this means that if you host multiple applications on the same domain, their cookies may conflict):
:path
Whether this cookie is secure (secure cookies are only transmitted over HTTPS connections; the default is false):
:secure
Finally, Rails provides a quick and easy way to delete cookies:
cookies.delete :user_id
Of course, every Ruby hash implements a delete method, but the cookies hash is a little different. It includes special code so that not only does calling delete remove a key-value pair from the cookies hash, it removes the corresponding cookie from the user's browser.
See Also
- Recipe 3.5, "Doing Date Arithmetic"
- Recipe 15.11, "Setting and Retrieving Session Information," has a discussion of when to use cookies and when to use session
Next: 15.13 Extracting Code into Helper Functions >>
More Ruby-on-Rails Articles
More By O'Reilly Media
|
This article is excerpted from chapter 15 of the Ruby Cookbook, written by Lucas Carlson and Leonard Richardson (O'Reilly, 2006; ISBN: 0596523696). Check it out today at your favorite bookstore. Buy this book now.
|
|