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
|