Ruby-on-Rails
  Home arrow Ruby-on-Rails arrow Page 3 - Understanding Controllers in Ruby-on-Rails
Dev Articles Forums 
ADO.NET  
Apache  
ASP  
ASP.NET  
C#  
C++  
ColdFusion  
COM/COM+  
Delphi-Kylix  
Design Usability  
Development Cycles  
DHTML  
Embedded Tools  
Flash  
Graphic Design  
HTML  
IIS  
Interviews  
Java  
JavaScript  
MySQL  
Oracle  
Photoshop  
PHP  
Reviews  
Ruby-on-Rails  
SQL  
SQL Server  
Style Sheets  
VB.Net  
Visual Basic  
Web Authoring  
Web Services  
Web Standards  
XML  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
RUBY-ON-RAILS

Understanding Controllers in Ruby-on-Rails
By: APRajshekhar
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 14
    2006-08-08

    Table of Contents:
  • Understanding Controllers in Ruby-on-Rails
  • Routing the Requests, and Session Tracking
  • Filtering and Verification, and Caching
  • Rails in the Real World

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Understanding Controllers in Ruby-on-Rails - Filtering and Verification, and Caching


    (Page 3 of 4 )

    3. Filtering and Verification

    There are situations where certain processing must be done before a request is serviced. In such situations filters come into the picture. Filters are pieces of code that wrap the logic that needs to be called before or after any number of actions within the controller or its derived classes. There are two kinds of filters, before and after filters. The before filters work before a request has been processed, whereas the after filters do the task after the action has been invoked. For example, if a code for verifying a user's session must be called before invoking an action, the code would be:

      def authorize
       
    unless session[:user_id]
         
    flash[:notice] ="Please log in"
         
    redirect_to(:controller =>"login", :action =>"login")
       
    end
     
    end

      class AdminController < ApplicationController
       
    before_filter :authorize
     
    # ...

    Here the code to be executed before invoking any action within the AdminController is wrapped inside the authorize function, which is then called before any other action using the before_filter. The after_filter also works in the same way.

    Filters can only call a code to be executed, but in situations where the need is to verify that a certain condition is met before an action is executed, filters can't do much. It is here that verification comes handy. Verification can be done by using the verify. Let's visualize a situation where the conditions are: the user-id must be valid, the user can only post comments, and if the conditions are met, redirect to the index page. The code using verify would be:

      class BlogController < ApplicationController
       
    verify :only => :post_comment,
              
    :session => :user_id,
              
    :add_flash => { :note =>"You must log in to comment"},
              
    :redirect_to => :index

      # ...

    Its that easy.

    4. Caching

    Rendering the same content again and again puts a heavy load on the server. To counter such a case, caching is used. For example, an action render_one that is being called again and again would be a good candidate for caching. Indeed, caching is a requirement here.

    In RoR caching can be done using the caching declaration. The caching can be page-level, action level, or both. To cache pages the declaration caches_page has to be used, and to cache actions the caches_action needs to be used. For example, in a blog management application, if the publicly viewable contents have to be cached the code would be:

    class ContentController < ApplicationController
      before_filter :verify_premium_user, :except => :public_content
      caches_page :public_content

    That ends the overview of the functionalities provided by the ActionController. In the near future I will discuss these in greater depth. But for now let's move on to the next section, which features an example of using the Controller for processing.

    More Ruby-on-Rails Articles
    More By APRajshekhar


       · Controllers are the ones that control the flow of logic in any MVC based framework....
       · Is there a link to the "last part" you mentioned, where the Say application can be...
     

    RUBY-ON-RAILS ARTICLES

    - Calculating Statistics with Active Record
    - Creating Graphs with Ruby
    - Callbacks and the Active Record
    - Validation and the Active Record
    - Arrays, Associations and the Active Record
    - Associations and Dependencies with Active Re...
    - Advanced Active Record: Enhancing Your Models
    - Load Balancing Databases with Rails
    - More Advanced Database Features and Rails
    - Handling Advanced Database Features with Rai...
    - Managing Database Files with Ruby on Rails
    - Databases and Ruby on Rails
    - Updating and Deleting with the Active Record
    - Rails Active Record and CRUD Functions
    - Working with a Database: Active Record







    © 2003-2010 by Developer Shed. All rights reserved. DS Cluster 12 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek