Before we start implementing access control, we should get our application ready by encapsulating all access control checks. First, in app/helpers/login_sessions_helper.rb, change current_user_can_edit to the following (WILL BREAK):

  def current_user_can_edit article
    current_user and current_user.can_edit? article
  end

This means that we need to implement User.can_edit?. For now, just use the previous code from the helper:

class User
  # ...
  def can_edit? article
    article.user_id == self.id
  end
end

Finally, make sure we use the same access check in app/controllers/articles_controller.rb (notice that the filters for edit, update and delete require a user who can edit the article, but new and create only checks that the user is logged in):

class ArticlesController < ApplicationController
 
  before_filter :can_edit, :only => [ :edit, :update, :delete ]
  before_filter :verify_logged_in, :only => [ :new, :create ]
 
  # ...
  # All actions go here
 
private
  def can_edit
    @article = Article.find(params[:id])
    unless @article and current_user and current_user.can_edit? @article
      redirect_to_login
    end
  end
end

Implement redirect_to_loginapp/controllers/application.rb:

class ApplicationController < ActionController::Base
  # ...
 
  def redirect_to_login
    flash[:notice] = "You must login in to do this"
    session[:redirect_after_login] = request.request_uri
    redirect_to new_login_session_path
  end
 
end

Finally, changes all places in app/controllers/articles_controller.rb where we fetch articles through the current user. The security check that these provided is now obsolete. Search for current_user.articles and replace with Article (if you oode reads current_user.articles.build, the new code must say Article.new).

Our application logic is now ready for custom permissions.

Creating a permissions model

I like to think of permissions as resources, just like articles, comments and users. However, since we may potentially want to add many permissions at the same time, we need a custom controller. This will be a basic lesson on creating a somewhat strange controller to edit a many-to-many relationship. Here are the steps needed:

1. We start by creating the model for the permissions: ruby script/generate model permission editable_article_id:integer editor_id:integer
2. Enter the migration into the database: rake db:migrate
3. Create the controller. Let’s just give it a few actions: ruby script/generate controller permissions show edit create.
4. Make the controller a nested resource of the articles. In config/routes.rb, add the following inside the map.resources :articles section: article.resource :permissions, :name_prefix => nil (notice the singular form for “resource”)
5. http://localhost:3000/articles/article_id/permissions/ should now take us to the show page for the permissions of an article. It’s currently empty. This is how we want it to look (THIS WILL FAIL):

   <h2>Users who can edit <%= @article.title %></h2>
    
   <ul>
   <% for editor in @article.editors - [@article.user] %>
     <li><%= editor.username %> (<%= editor.full_name %>)</li>
   <% end %>
   </ul>
    
   <%= link_to "Edit", edit_permissions_path(@article) %></small>

6. In order to get the @article object, put the following in app/controllers/permissions_controller.rb’s definition of show: @article = Article.find(params[:article_id]).
7. For this to work, Article.editors must be implemented. First, associate articles with permissions: has_many :permissions, :foreign_key => 'editable_article_id' (notice that the foreign_key option matches what we put in the migration). Second, make the permission know about editors: In app/model/permission.rb: belongs_to :editor, :class_name => "User" (Notice that we have to specify the class name, as it is not the same as the association). Lastly, make articles associated with editors through the permission association: has_many :editors, :through => :permissions. If you refresh the permissions page, it should now give an empty list, as expected.
8. For the edit page, we want to display all users with a checkbox that shows whether that user has a permission to edit the article or not. Here’s my code for app/views/permissions/edit.html.erb:

   <h1>Permissions for <%= @article.title %></h1>
    
   <% form_for :article, :url => { :article_id => @article, 
                                   :action => :update } do |f| %>
     <% for user in User.find(:all) - [@article.user] %>
       <div>
         <%= check_box_tag "article[editor_ids][]", user.id, 
                           @article.editors.include?(user) %>
         <%= user.username %> (<%= user.full_name %>)
       </div>
     <% end %>
     <p>
       <%= f.submit "Update" %>
     </p>
   <% end %>

9. To get the code to display correctly, implement app/controllers/permissions_controllers.rb edit as follows: @article = Article.find(params[:article_id]).
10. So far, so good. Now comes the hard part: Updating the association on the post. The following is inspired from Ryan Bates’ excellent screencast on many-to-many associations with checkboxes. First, notice how the name of the check_box_tag ends with “[]“? This is to let ail know that we intend for all “article[editor_ids]” values to come in as an array. If you take a look at the application log, you will see something like this: Parameters: {"article"=>{"editor_ids"=>["618895042", "618895044", ..... Second, a has_many :editors association will generate an attribute for editor_ids, as well an attribute for editor. Put these to facts together, and you get the following simplified implementation of PermissionsController.update:

      def create
        @article = Article.find(params[:article_id])
        @article.editor_ids = params[:article][:editor_ids]
        if @article.save
          flash[:notice] = 'Permission was successfully created.'
          redirect_to(permissions_path(@article))
        else
          render :action => "edit"
        end
      end

11. Aaaaand, we're done!
12. Well, not quite - there's a gaping security hole. Can you see it? If not, don't worry, we'll get back to it.

Using the new security features

Since we prepared our application for the new security implementation, getting it to take effect is extremely simple, just update app/model/user.rb's can_edit? method to the following: article.user_id == self.id or editable_articles.include? article. In order for this to work, we need to create a relationship from user to articles, like we did for the other direction:

1. class User has_many :permissions, :foreign_key => :editor_id
2. class Permission belongs_to :editable_article, :class_name => 'Article'
3. And class User has_many :editable_articles, :through => :permissions

That's it. We're ready to test:

1. Log in as a user who owns an article
2. Navigate to the article. The edit link should be visible.
3. Add permissions to the URL (you might want to create a link_to this page!)
4. Click the Edit link
5. Give a few users permission to edit the article by checking their names and clicking submit
6. Log in as a different user who now should have edit permissions for the article
7. Navigate to the article. The edit link should now be visible.
8. Outstanding

Who watches the watchmen?

Have you found the security hole yet? The problem is simply that any user can modify the permissions for an article, giving themselves access to edit the article. We could fix this by protecting the permissions like we protect the articles, but instead, I want to demonstrate how to use multiple permission schemes.

1. We start by adding a much wanted link. In app/views/articles/edit.html.erb, add the following (WILL BREAK): <% if current_user.can_admin? @article %><%= link_to 'Change editors', edit_permissions_path(@article) %><% end %>.
2. This will break, because we need to let app/model/user.rb implement the can_admin? method. Here's a possible implementation: def can_admin? article; article.user_id == self.id; end. We could imagine other rules for this, for example with a different set of permissions for administrating an article, or a field on the permissions that determined the access level.
3. To avoid the user from manually entering the URL, make sure to protect app/controllers/permissions_controller.rb as well:

   class PermissionsController < ApplicationController
     before_filter :can_admin, :except => [ :show ]
     # ...
   private
     def can_admin
       @article = Article.find(params[:article_id])
       unless @article and current_user and current_user.can_admin? @article
         redirect_to_login
       end
     end
   end

4. Protect the edit link in app/views/permissions/show.html.erb as well: <% if current_user and current_user.can_admin? @article %><%= link_to "Edit", edit_permissions_path(@article) %><% end %>
5. This effectively protects the permissions from being edited by anyone except the original author of the article

A detour to increase our speed

When you start creating more Rails applications, you will quickly notice that the place where performance bottlenecks occur is with the access to the database. In our example, changing the permissions is particularly prone to being slow, as it currently fetches the user for every checked line it displays.

In order to prevent this, we can include the user information when looking for the permissions. The way to do this is to specify the extra information to be fetched right away on the Article.find. It basically looks like this: Article.find(params[:article_id], :include => :editors). :include is a powerful feature with lots of options. Make sure you understand it, or your applications will be slow.

A the end of our journey?

This article completes the construction of our blog application. Along the course of the set of articles, we have implemented one-to-many relationships, RSS, AJAX, learned about sessions and authentication, looked at many-to-many relationships in order to implement access control.

These articles show you much of the power of Rails as a web framework. However, we haven’t touched any of subjects needed to have an effective development process with Rails. Rails is often used together with Capistrano, which gives support for actually deploying applications to a server. In addition, we have only scratched the surface of the test options that exist for Rails.

This series of articles is at an end, but I am considering writing a few article on practical testing and deployment with Rails. Stay tuned for more Rails goodness.

In this tutorial, I will show you how to make sure that only logged in users can create articles, and that nobody else can edit an article that you created.

The task at hand

This is basically what I want to say:

class ArticlesController < ApplicationController
 
  before_filter :verify_logged_in, :except => [ :index, :show ]
 
  def new
    @article = current_user.articles.build
  end
 
  def edit
    @article = current_user.articles.find(params[:id])
  end
 
  def create
    @article = current_user.articles.build(params[:article])
    # save it...
  end
 
  def update
    @article = current_user.articles.find(params[:id])
    # save it...
  end
 
  def destroy
    @article = current_user.articles.find(params[:id])
    # delete it...
  end
 
private
 
  def verify_logged_in
    unless current_user
      # redirect to login dialogue
    end
  end
end

In plain English: Verify that the user is logged in before any other actions than index and show are performed. This boils down to the method current_user returning a non-nil result. Use the current_user as starting point when creating or updating articles.

Now we just need to create the login functionality. This means some way of creating users and making these users log in. There is actually a plugin called restful_authentication that does this for you, but it’s not that hard, so I though we could do it on our own.

The users model

The key to this business is obviously the verify_logged_in method. Let’s try this:

  def verify_logged_in
    unless current_user
      redirect_to new_login_session_path
    end
  end

What is this current_user thing?

  def current_user
    User.find(session[:user_id]) if session[:user_id]
  end

Here, we use a session variable to store the user_id, and look up the a User model using this session variable. You should never store ActiveRecord objects in session variables.

By now, it is becoming blindingly obvious that we need a User model. Let’s use the generator:

ruby script/generate model User username:string password:string

We also want to associate the articles with users. Add has_many :articles in app/models/user.rb, and belongs_to :user in app/models/article.rb. Also add the following to your newly generated migration in db/migrate/003_create_users.rb:

class CreateUsers < ActiveRecord::Migration
  def self.up
    # ...
    add_column :articles, :user_id, :integer
  end
 
  def self.down
    remove_column :articles, :user_id
    # ...
  end
end

You can now execute rake db:migrate to update the database structure.

Logging in

Next order of business: verify_logged_in contained the line redirect_to new_login_session_path. If you guessed that we are going to have a resource called “login_session”, and that this is just like when we said “new_comment_path”, you guessed right! This means we have to add the following to config/routes.rb: map.resource :login_session.

A user should only be aware of one login_session, so we say map.resource (singular) instead of map.resources plural. A typo here can be very confusing.

Now, create the LoginSessionsController by executing ruby script/generate controller LoginSessions new create show destroy on the command line. We can now update our new app/controllers/login_sessions_controller.rb. Notice how we use the conventions from other restful controllers of standardized action names for new, create, show and destroy, even though there is no login_session model:

class LoginSessionsController < ApplicationController
 
  def new
  end
 
  def create
    @user = User.authenticate(params[:login][:username], params[:login][:password])
    if @user
      session[:user_id] = @user.id
      redirect_to :action => "show"
    else
      render :action => "new"
    end
  end
 
  def show
    @user = current_user
    if !@user
      redirect_to :action => :new
    end
  end
 
  def destroy
    session[:user_id] = nil
    redirect_to :action => :new
  end
 
private
 
  def current_user
    User.find(session[:user_id]) if session[:user_id]
  end
 
end

The form for logging in is located in app/views/login_sessions/new.html.erb and looks like this:

<h1>Log in</h1>
 
< % form_for :login, :url => { :action => :create } do |f| %>
 
<p>< %= f.label :username %>: < %= f.text_field :username %></p>
<p>< %= f.label :password %>: < %= f.password_field :password %></p>
 
<p>< %= f.submit "Log in" %></p>
< % end %>

I have also made it possible to log out from the show-view by having a logout "form" in app/views/login_sessions/show.html.erb:

<h1>Current session</h1>
<p>You are logged in as < %= @user.username %></p>
 
< % form_tag '/login_session', :method => :delete do %>
  < %= submit_tag "Log out" %>
< % end %>

(I'm not totally happy with this - suggestions for improvements are welcome!)

Everything now works - trust me!

Testing the code

Okay, don't trust me. God knows I wouldn't trust me. You should obviously test your code. Normally, you would test this sort of logic using test classes, but I haven't covered this yet, so we'll have to be satisfied with manual testing for now.

In article 4 in this series, I introduced fixtures. Fixtures are located under test/fixtures, and when you used the generator to create the user model, a fixture was generated for you as well in test/fixtures/users.yml. Update this to contain two test users with passwords. I use the following:

user1:
  username: user1
  password: password
 
user2:
  username: user2
  password: password

Also, make sure that the article fixtures in test/fixtures/articles.yml contain reference to the users. Here is one of my articles:

two:
  user: user1
  title: Romans, Brothers, Fellowmen
  author: Marcus Aurelius
  content: I stand here before you bearing witness of a <b>miracle</b>

You can now reload the fixtures with rake db:fixtures:load. Then test as follows:

1. Go to an article and press the "edit" link. You should now be redirected to the login page
2. Enter the username and password to your user who own the article from test/fixtures/users.yml and press "Log in". You should now be taken to a page that shows your login status
3. Navigate back to the article edit page. You should now be able to edit the article.
4. Navigate back to the login status page (http://localhost:3000/login_session) and press "Log out". You should now be returned to the login form.
5. Log in as a user who does not own the article.
6. Navigate back to the article edit page. You should now be presented with an error message stating that there is no article with this id and user_id.

Our rudimentary security now works correctly, and we can rest soundly. Or we can polish it to make it nicer. Which one is it going to be? You know me by now: Let's get out the belt sander.

Making it nice

There are many things we need to do to make this actually usable. We have our work cut out for us. Let's get started:

1. Show current login status on all pages. In app/views/layouts/articles.html.erb, add <% if current_user %><p>Logged in as <%= link_to current_user.username, :controller => :login_sessions, :action => :show %></p><% end %>, and copy current_user from the articles_controller to app/helpers/login_sessions_helper.rb
2. Most importantly: Let's remove the "edit" link when the user can't edit the current article. This avoid confusion, and means that we don't have to fix the ugly error message for people trying to edit other people's articles. Here's how: In app/views/articles/show.html.erb, put the following around the edit link: &lt% if current_user_can_edit @article %> ... <% end %>. Define the current_user_can_edit method in app/helpers/login_sessions_helper.rb as follows: article.user == current_user
3. Give a friendly message when we redirect someone to log in. We do this using the flash. The flash is a special session which is cleared after a the next request. We use it when we're redirecting, and normally would put something in "@" instance variables, as instance variables don't survive a redirect. In app/controllers/articles_controller.rb, add the following in verify_logged_in before redirecting: flash[:notice] = "You must login in to do this". In app/views/login_sessions/new.html.erb, add the following to the top of the page: <p style="color: green"><%= flash[:notice] %></p>
4. Add a message if login failed. In app/controllers/login_sessions_controller.rb, add the following to the else block of create: flash[:error] = "Login failed". In app/views/login_sessions/new.html.erb, add the following to the top of the page: <p style="color: red"><%= flash[:error] %></p>. As an extra exercise: Can you create a generic construct to list all items in the flash (use flash.each_pair) and display them with proper formatting (update public/stylesheet/scaffold.css)?
5. If a user was diverted to the login page, redirect the user back to the page he wanted to go to after a successful login. In app/controllers/articles_controller.rb, add the following in verify_logged_in before the redirect: session[:redirect_after_login] = request.request_uri. In app/controllers/login_sessions_controller.rb, change the redirect in create to the following: redirect_to(session[:redirect_after_login] || { :action => 'show'})
6. Allow for http authentication to allow web service clients to access restricted operations without having to simulate a login dialog. If you have Cygwin, or you're working on a UNIX platform, you can test this by using the command line tool "curl": curl http://localhost:3000/articles/id/edit will redirect, but curl --user username:password http://localhost:3000/articles/id/edit will work if we make the following change: In app/controllers/articles_controller.rb, add the following to the start of current_user: if !session[:user_id] && user = authenticate_with_http_basic { |u, p| User.authenticate(u,p) }; session[:user_id] = user.id; end
7. Never store clear text passwords in the database. We can hash the passwords first. In app/models/user.rb, make the following changes:

   class User < ActiveRecord::Base
     has_many :articles
    
     def password=(value)
       write_attribute :hashed_password, User.hash_string(value)
     end
    
     def password
       ""
     end
    
     def self.authenticate(username, password)
       find_by_username_and_hashed_password(username, hash_string(password))
     end
    
     PASSWORD_SALT = "slgn3woihtrwoe1902"
    
     def self.hash_string(string)
       Digest::SHA1.hexdigest(string + PASSWORD_SALT)
     end
   end

   Also update the migration by replacing the password column with hashed_password, and rerun the last migration with rake db:migrate:redo. Finally update the test/fixture/users.yml and replace the password lines with the following: hashed_password: <%= User.hash_string "password" %>. Reload the fixtures with rake db:fixtures:load. Everything will behave as before, but the passwords are no longer stored in clear text.

8. Fix the tests: All the tests in test/functional/articles_controller_test.rb of methods that require login will now fail. The get, put, post and delete methods that the tests use are all designed with this problem in mind. They all take up to three parameters: The action, the arguments, and the current session. So, for example, in test_should_create_article the line post :create, :article => { } should be replaced by post :create, { :article => { } }, { :user_id => users(:user1).id }, and the first line in test_should_update_article should be put :update, { :id => articles(:one).id, :article => { } }, { :user_id => articles(:one).user_id }. You can find more information about testing controllers in A Guide to Testing the Rails, by Steve Kellock and Chris Carter.
9. Allow for the creation of new users. Whoops! Currently, only the users already in the database are available. That won't really work, will it? First, let's add a few details to the user model: ruby script/generate migration AddDetailsToUser email:string full_name:string bio:text and rake db:migrate. Then, create the controller and views for the user scaffold: ruby script/generate scaffold --skip-migration user username:string password:string email:string full_name:string bio:text. You will need to make a few simple changes: Remove password from show.html.erb and index.html.erb, and replace text_field for password in edit.html.erb and new.html.erb with password_field. You will probably also want to have a before_filter :verify_logged_in, :only => [ :edit, :update, :destroy ] in app/controllers/users_controller.rb. Move verify_logged_in and current_user to app/controllers/application.rb to reuse these methods between the different controllers.
10. There are still many things left to do with the users to make them secure and well-functioning. But that's going to be the subject of a future post.

Don't mess with my articles!

We have implemented functionality for logging in, and for restricting access to an article. It turns out that using the relationships between the user object and articles is a good way to ensure that a user is only allowed to edit his own articles. Using ActiveRecord to execute find on an association instead of a class minimizes the risk of leaving security holes open by accident. There's still a lot to learn about security however. In my next post, I will show you how you can let users grant access for other users to edit their posts. I might also touch on a few odds and ends regarding validation. Stay turned.

One of the remarkable things about Rails is that it lets you get up and running very quickly. Here is what you need to do to get your first application up and running on Heroku.

1. Apply for an account on heroku (or mail me for an invitation)
2. When you have gotten your account set up, go to the heroku page for your applications and log in.
3. Press the big button labeled “Create New App”
4. Click the button that look like a gear in the lower left hand corner and choose “generate” from the pop-up menu.
5. Enter scaffold article title:string author:string content:text and click “run”
6. Press the yellow text labeled “Migrate now” to create the articles table in the database
7. (Optional) Select “rake” from the gear pop-up menu and type test
8. (Optional) In the “rake” window, type db:fixtures:load to populate the database with test data
9. Press the button with two right arrows (“>>”) on the top right corner and you will be taken to your application, done being installed on the heroku server. Add /articles to the url to see your newly generated application
10. You can now play around with creating, retrieving, updating and deleting articles
11. Click the button with two left arrows (“<<") on the bottom of the screen to return to the IDE
12. (Optional) Make the application publicly available. Click the name of the application (“unnamed-xxxx” on the top left corner). Pick a name for your application, select “Public” to have it deployed to the net, and press rename

You now have a fully working, running, deployed Rails application. It requires no installation on your part. From here, you can follow the rest of my articles on Rails pretty much straightforward. Welcome aboard.

My pretty, pretty articles

Our articles are currently not formatted. We want to support a simple markup language. As it turns out textile is perfect for the job. It transforms stuff “*like* _this_” to stuff “like this“. Let’s add textile support:

1. Ruby support for textile is available in the RedCloth gem. Install it by typing gem install RedCloth on the command line.
2. Import RedCloth in your Rails application. In config/environment.rb add the line require 'RedCloth' (after the other line that starts with ‘require’).
3. Let’s add a helper for textile for all views. In app/helper/application_helper.rb, add the following:

   def textile(text)
     RedCloth.new(html_escape(text)).to_html
   end
   def intro(text)
     paras = text.split /\n\n/
     textile paras[0]
   end

4. Update the views: In app/view/articles/show.html.erb change <%=h article.content %> (“h” is short for html_escape) and replace with <=textile article.content %>. Similarly change app/view/comments/_comment.hml.erb and replace <%=h comment.body %> with &l;%= textile comment.body %>. (We will deal with the article index later)
5. Try adding some textile markup to your articles and test out the effect. You can put your test data in test/fixtures/articles.yml and load it with rake db:fixtures:load if you’re too lazy to type it in the forms.

A good first impression

If you’ve followed the article series, when you go to http://localhost:3000, you are presented with the default Rails-constructed start page. Lets make a more inviting web page and start at the articles page instead:

1. In config/routes.rb, add a root route: map.root :controller => 'articles'. The comments in the file describes this further.
2. Files in the public/ folder will take precedence over the routes, so you also need to delete public/index.html.
3. If you go the http://localhost:3000, you will now be presented with the articles list. It looks horrible. Let’s clean up app/views/articles/index.html.erb. Here is my final version (the intro function was defined earlier in this blog post):

   <h1>Welcome to my blog</h1>
    
   < % for article in @articles %>
     <div class="article" id="<%= dom_id(article) %>">
       <h2>
           < %= link_to h(article.title), article %>
           <small>(by < %= article.author %>)</small>
       </h2>
       <div class="body">< %= intro article.content %></div>
     </div>
   < % end %>
    
   <br />
    
   < %= link_to 'New article', new_article_path %>

4. We also need rss feeds for all our pages. Luckily, Rails comes with lots of built in support for this. First: We want to add auto discovery of the link in browsers that support this. app/view/layouts/articles.html.erb is applied around each page from the articles-controller, with the contents being displayed where the layout says <%= yield %>. Add the following to the <head> in app/view/layouts/articles.html.erb: <%= auto_discovery_link_tag :rss, { :controller => 'articles', :format => :rss } %>. If you refresh the page, you may notice a small RSS icon in the address bar of your browser! If you want to make the blog look nicer, the layout is also a good place to start.
5. Clicking the RSS icon lets you go to the RSS action. However, this just takes you to a blank page. You have to go to app/controllers/articles_controller.rb add a line to the index action’s respond_to block with format.rss. Refreshing will now give you a proper error message: “Missing template articles/index.rss.erb”
6. Create a file named app/views/articles/index.rss.builder. Files with “.builder” extensions are regular Ruby files, but in these files, a special object named xml is available (much like the “rjs” files we worked with earlier). We can use this to create RSS feeds. (w3schools have a useful RSS syntax reference). Here is mine:

   xml.rss :version=>"2.0" do
     xml.channel do
       xml.title "My cool blog"
       xml.link articles_url
       xml.description "I have made a blog - take a look"
       for article in @articles
         xml.item do
           xml.title article.title
           xml.link article_url(article)
           xml.description intro(article.content)
         end
       end
     end
   end

7. Refreshing the feed will now give you a complete RSS feed and the option to subscribe to it if your browser supports this.

Did they respond to my comment?

Many blogs lack a RSS for comments. This means that you’ll have a hard time keeping track of whether someone responded to our comment. We want to do better, and learn some more about routing at the same time:

1. Add another auto discovery link to app/views/layouts/articles.html.erb after the first one: <%= auto_discovery_link_tag :rss, { :controller => 'comments', :article_id => @article, :format => :rss }, { :title => 'Comments' } %>.
2. Go to an article that has some comments, and click the RSS icon by the address bar. In Firefox, this will how a menu of the two feeds, both labeled “Subscribe to ‘Comments’”. Click the link to view the comments feed.
3. Creating the feed will be just like the article feed: You have to add format.rss to the respond_to block for the index action of app/controllers/comments_controller.rb and add app/view/comments/index.rss.builder. Go ahead and do that now.
4. In app/view/comments/index.rss.builder, I made the item link point to xml.link comment_url(comment). You will have to define comment_url in app/helpers/comments_helper.rb (pay attention to the :only_path parameter):

   def comment_url(comment)
     url_for :controller => 'comments', :action => 'show', 
         :article_id => comment.article, :id => comment, 
         :only_path => false
   end

5. We have let comment_url and comment_path in both app/controllers/comments_controller.rb and app/helpers/comments_helper.rb point to the comments view. This is a pretty lame page, and we don’t want to make separate pages for the comments anyway. Instead: Hyperlink to an anchor to the comments: :controller => 'articles', :action => 'show', :id => comment.article, :anchor => dom_id(comment) in both the helper and the controller. Now all our links are fixed with one fell swoop! Delete app/views/comments/show.html.erb while you’re at it. This will break your tests in test/functional/comments_controller_test.rb so make sure you fix them. Both test_should_create_comment and test_should_update_comment should redirect to assert_redirected_to article_path(:id => assigns(:article), :anchor => @controller.dom_id(assigns(:comment))). test_should_show is no longer valid and can be deleted.

We now have a nice feed for the articles and comments, with hyperlinks that take us to the right place. However, we have opened a problem: If you try to subscribe to comments from the front page, you will get angry error messages about the fact that you can’t find the related article to search for comments for. We could avoid displaying this link when there’s no active article by doing something like <%= auto_discovery_link_tag .... if @article %>, but instead, we’ll use the chance to learn how to create a route for all comments.

1. The problem starts with app/controllers/comments_controller.rb in the method find_article. Change the contents of the method to @article = Article.find(params[:article_id]) if params[:article_id]. This moves the problem to the index action. Change the first line to use Comment.find if there’s no article: @comments = @article ? @article.comments.find(:all) : Comment.find(:all) (For extremists, this could be written: (@article ? @article.comments : Comment).find(:all)).
2. You will also have to update app/views/comments/index.rss.builder to deal with @article being nil. For the channel link, I did: xml.link @article ? article_url(@article) : all_comments_url. But what is all_comments_url?
3. Enter config/routes.rb. Add the following route: map.resources :comments, :name_prefix => 'all_'. Your view now works. And what is more, you can even go directly to http://localhost:3000/comments to view all comments. But in order for this to work, you will have to update app/views/comments/index.html.erb and remove the link to create a new comment.

An issue of trust

We have created a blog with quite a few nice features: Comments, AJAX-support, RSS feeds and formatting. If you have been following along, I hope you have been impressed with the speed with which you can create an application in Ruby-on-Rails.

However, if you’ve been working with development for any time, you have probably seen quite a few examples of technology which starts of promising, but then falls apart when you try to create something that could actually be usable in the real world. So the next time, I plan to do the responsible thing and add security and authentication, so that not just anybody can create and edit articles! In the process, we will get to use sessions and more advanced active record relationships.

A view to die for

First, clean up app/views/articles/show.hml.erb. I am assuming you know enough HTML to be able to make it look reasonably blog like. Following is a suggested starting point. The only thing that is critical to follow allow the text of this tutorial, is the id of the “new_comment” div. This will be used as a target for our AJAX code.

<div class="article">
  <h2><%=h @article.title %></h2>
  <h3>
    By <%=h @article.author %>
    <small><%= link_to "[ edit ]", edit_article_path(@article) %></small>	
  </h3>
 
  <%=h @article.content %>
</div>
 
<div id="comments">
  <h2>Comments</h2>
 
  <% for comment in @article.comments %>
    <div id="<%= dom_id(comment) %>" class="comment">
      <h3><%=h comment.title %> (by <%=h comment.author %>)</h3>
      <p><%=h comment.body %></p>
    </div>
  <% end %>
 
  <div id="new_comment">
    <h2>Add your comment</h2>
    <%= error_messages_for :comment %>
    <% form_for :comment, :url => comments_url(@article) do |f| %>
      <p><%= f.label :title %> <%= f.text_field :title %></p>
      <p><%= f.label :author %> <%= f.text_field :author %></p>
      <p><%= f.label :body %> <br /><%= f.text_area :body, :rows => 5 %></p>
      <p><%= f.submit "Create" %></p>	
    <% end %>
  </div>
</div>

Partially better

The easiest way to use Rails AJAX support is to redraw parts of the view from the server. You can remove many sources of error by making sure that you’re using exactly the same HTML + ERb code to render the new views from the AJAX requests. This is a good place to introduce another Rails technique: Partials.

1. Replace the code from <% for comment %> to the corresponding <% end %> section with a call to render method like so: <%= render :partial => 'comments/comment', :collection => @article.comments %>
2. Move the <div> used for the comment to a new file, app/views/comments/_comment.html.erb
3. The call to render :partial means to call the file app/views/comments/_comment.html.erb for each comment in @article.comment. Each comment will be assigned to the variable comment in turn.
4. That’s it – your comment code is refactored out

Second, we do the same with the form for adding new comments:

1. Replace the <div id="new_comment"> for new comments with a call to another partial: <%= render :partial => 'comments/new' %>
2. Move the code for the new comment unchanged into a new file called app/views/comments/_new.html.erb.

The view still looks the same in the browser, but we’re now posed to awe the world with our mad AJAX skills.

AJAX

Using AJAX is very easy, so I will just jump straight into it:

1. Make the client loads the necessary Javascript files: Add the line <%= javascript_include_tag :defaults %> to the <head> section in app/views/layout/articles.html.erb. I bet you wondered where the title on the pages came from. Now you know.
2. In app/views/comments/_new.html.erb, replace the call to form_for with an identical call to remote_form_for.
3. In theory, this is all you need to do, and your form is now AJAX enabled, but we also have to specify what actions should be performed when the submit button is pushed. Right now, if you fill in a form and press submit, it will look as if nothing is happening. But if you refresh the page, you will see that the comment was indeed added to the database.
4. Declare that creating a comment should support AJAX: In app/controllers/comments_controller.rb, find the method create and add format.js in the “if” block of method. Notice that no {} or anything is needed for this line (just like with most format.html calls in the other controller methods).
5. Add the file app/views/comments/create.js.rjs. This will contain the code for what should be rendered when the user submits the form.
6. RJS files are plain Ruby files, with a special object called page available. In app/views/comments/create.js.rjs, just enter a single line: page.insert_html :before, 'new_comment', :partial => "comments/comment"
7. That’s it, if you post a comment, after some delay, it is displayed right before the new comment form.

Make it good

The AJAX now works, but it leaves a lot to be desired. Here are some improvements:

1. Make the new comment stand out visually after it is created. Add the following to app/views/comments/create.js.rjs: page[dom_id(@comment)].visual_effect :highlight. (Or pick another effect from the script.acol.us webpage)
2. Clear the form. Add the following to app/views/comments/create.js.rjs:

   @comment = Comment.new
   page['new_comment'].replace :partial => "comments/new"
   page['new_comment'].visual_effect :slide_down

3. Add a progress indicator: In app/views/comments/_new.html.erb, add the following line inside the “new_comment” div: <div id="progress" style="display: none">Saving...</div> and the :loading option to the call to remote_form_for: :loading => "Element.show('progress')".
4. Even better, create a progress indicator at ajaxload.info. Download the image as public/images/ajax-loader.gif, and replace the contents of the progress div with <%= image_tag "ajax-loader.gif", :alt => "saving..." %>.
5. Error handling doesn’t work. If you add some validation to the model, you will notice that the page behaves very poorly when the validation fails. Add the following line to app/models/comment.rb: validates_presence_of :title, :author, :body. If you try to submit a form that is missing one of these fields, the page will never update and the progress indicator will just keep going. To fix this, you can add the following line to the “else” block of the create method of app/controllers/comments_controller.rb: format.js { render :update do |page| page['new_comment'].replace :partial => 'new'; end }. This acts just as the RJS template from before, but without using a separate file (if you make this change, you will have to update your tests).
6. You might also want to do something about the “flash”, but explaining that requires too much details, so I will leave that for another day.

AJAX goodness

We’ve covered the basics of AJAX: Using partials to make your views flexible, using remote_form_for to make the form submit asynchronously using JavaScript, and using RJS templates to generate JavaScript using Ruby.

There are many other options for using AJAX out there, and you might want to explore the field further. Ultimately, nothing beats JavaScript for JavaScript. That being said, built-in AJAX support in Rails is my favorite way to get started.

I hope you’ve enjoyed this tutorial. Some of the topics I am considering covering now are: Sessions, XML and RSS, development howtos like deployment, testing and application structure, or something completely different. Thanks a lot your for comments to my previous articles via the blog or email. Let me know what you want next.

In this second article, I will expand the blog to allow comments to our articles. This will require us to get our hands a bit more dirty with the Rails code, but it won’t be too bad. And even better: If you complete the instructions in this article, you can call yourself a Rails programmer!

Are you ready to dive in head first?

The initial structure

1. Like in the example with the article model class, we create a comment model. ruby script/generate scaffold comment article_id:integer title:string author:string body:text. Notice the article_id column, which will be our foreign key to the article.
2. rake db:migrate db:fixtures:load test
3. You can now see the comments at http://localhost:3000/comments/

Connecting the comments to articles

To get the articles and comments connected, we need to do four things. I will take you thought the process in detail.

1. We have to update the routes for URLs to let Rails know how to connect articles to comments
2. We have to update the model classes for the two classes, to let them know about the relationship
3. We have to update the CommentsController to refer to the correct article when it finds, creates or modifies a comment.
4. We have to include the information about the comments in the article views.

Here we go:

1. Lets start with routing. The file config/routes.rb tells us how our application URLs are structured. Remove map.resource :comments, and add comments as a “nested route” instead:

    map.resources :articles do |article|
       article.resources :comments, :name_prefix => nil
     end

   This change means that you will find the comments like this: http://localhost:3000/articles/article-id/comments/

2. Update app/view/articles/show.html.erb so we can get the comments related to an article. Add the following code:<%= link_to "Comments", comments_path(@article) %>
3. http://localhost:3000/comments/ no longer works. Instead: Select an article, and click the new Comments link. This gives an error, because the routes we generated don’t take the relationship between articles and comments into consideration.
4. The best way to fix this is to change the methods we use to find comments. We can do this by updating the view helper in app/helpers/comments_helper.rb

   def comment_path(comment)
     url_for :controller => "comments", :action => "show",
         :article_id => comment.article, :id => comment
   end
   def edit_comment_path(comment)
     url_for :controller => "comments", :action => "edit", 
         :article_id => comment.article, :id => comment
   end

5. You now need to inform the model classes about each other via belongs_to and has_many associations. Update app/models/article.rb and app/models/comment.rb:

   class Comment < ActiveRecord::Base
     belongs_to :article
   end
   class Article < ActiveRecord::Base
     has_many :comments
   end

Updating the controller

If you click on the Comments link, you will now be rewarded with a seemingly meaningful set of comments for the current article. But appearances can be deceiving. We have still not made the controllers aware of the fact that only the comments for the current article should be displayed. If you click around in the application, it will soon become apparent that all comments are displayed under all articles! We need to update the controller to restrict to only comments for the current article.

1. Update app/controllers/comments_controller.rb, and make sure we always have an article available. This is usually done through a "before_filter". Add the following line to the beginning of the file: before_filter :find_article, right after the class line.
2. Implement the filter. Add the following to the very end of the class file, just before the final "end":

   protected
     def find_article
         @article = Article.find(params[:article_id])
     end

3. You can now replace every find and new on the Comment class with similar code in the article model. Replace every place where the code says Comment.find(...) with @article.comments.find(...), and every place the code says Comment.new(...) with @article.comments.new(...)
4. We also need to let the controller know how to redirect to a created or updated view. Add the following right after the end of the find_article code above.

    def comment_url(comment)
       url_for :controller => "comments", :action => "show",
           :article_id => comment.article, :id => comment
     end

5. Finally, we should never let the user give article_id in the input forms. To avoid this, you can add the line attr_protected :article_id to app/model/comment.rb

At this stage, creating, viewing, updating and deleting comments should all work as expected. However, before we turn to the view, you might have noticed a strange thing with our test data. The comments generated by running rake db:fixtures:load are not connected to the correct articles. The place to fix this is in test/fixtures/comments.yml, and the way to fix it is a new feature with Rails 2.0:

In test/fixtures/comments.yml, change the lines that read article_id: 1 into article: one. Regenerate the test data by running rake db:fixtures:load. Both articles should now be attached to your first article.

Integrating the views

Finally, we want to improve the way all this looks. Polishing the view will be the topic of my next article, so for now, let's just mash the information together.

1. We want to display all the comments in the details view for an article. Replace the link we created to the comments in app/view/articles/show.html.erb with the full contents of app/view/comments/index.html.erb
2. Still in app/view/articles/show.html.erb, replace <% for comment in @comments %> with <% for comment in @article.comments %< and <%= link_to 'New comment', new_comment_path %> with <%= link_to "New comment", new_comment_path(@article) %>. Your articles should now display the corresponding comments.
3. We also want our users to be able to add new comments when they view the article. Still in app/view/articles/show.html.erb, replace the "New comment" link with the full contents of app/view/comments/index.html.erb.
4. Replace <% form_for(@comment) do |f| %> with <% form_for :comment, :url => comments_path(@article) do |f| %> and remove the link <%= link_to 'Back', comments_path %>
5. If you look at the page for an article now, you will be rewarded with a functional, but ugly page that despite its appearance displays the article, all comments for the article, and allows the users to add new comments.

Fixing the tests

Before we leave, lets make sure that our tests still pass. Run rake test. You tests should fail at this point. This is because the tests don't supply the article_id attribute CommentsController now requires.

1. All post and get requests in test/functional/comments_controller_test.rb need have an argument :article_id => articles(:one) added to them. For example: get :index, :article_id => articles(:one). Do this for all the get and post requests in the test.
2. One test still doesn't run. In test_should_create_comment assert_redirected_to comment_path(assigns(:comment)) should be changed to assert_redirected_to comment_path(:id => assigns(:comment), :article_id => assigns(:article))
3. The tests should now pass.

Conclusion

This more lengthy post takes you through all the steps that are needed to create a web application that displays a one-to-many relationship, namely that of one article having many comments. We had to update both the URL routing to make comments a nested resource, the model class to associate the comments and articles, the controller to only find comments on the current articles and the article views to include the comment data, but every change is fairly simple.

Until this point, I have assumed that you as a reader don't know much about Rails. After completing this article, you have touched quite a few of the core concepts of Rails already. If you found the ride too confusing because I didn't provide a lot of details about the way a Rails application works, I would very much like to know it.

The next article in this series will clean up the view and add AJAX support.

Stay tuned, we are just getting started!

Before you start, you need to install Ruby on Rails: On Macs, Rails is already available and you can type the following commands in a normal terminal window. On Windows, you can get everything you need from InstantRails. Once you have unpacked InstantRails to a subfolder, start the “InstantRails.exe”. From the GUI that comes up, click the “I” button in the top left corner and select “Rails Applications” -> “Open Ruby Console Window” from the menu. The following commands should be typed in the command line window that shows up.

1. rails blogdemo
2. cd blogdemo
3. (Optional: Look at how generators work – read the documentation that is printed) ruby script/generate
4. (Optional: Look at how generators work – read the documentation that is printed) ruby script/generate scaffold
5. ruby script/generate scaffold article title:string author:string content:text
6. (Optional: Look for the documentation on the “rake” command) rake --tasks
7. (Optional: Look for the documentation on the “rake” command) rake -T db
8. rake db:create:all
9. rake db:migrate
10. (Optional: Load generated test data into the database) rake db:fixtures:load
11. (Optional: Run the generated tests) rake test
12. ruby script/server
13. You should now be able to view your wonderful application at http://localhost:3000/articles
14. Be sure to read the documentation at http://localhost:3000/ as well

Enjoy your first rails application!

If you find the results satisfying, you should start by exploring the directory structure of the files generated by Rails. In my next article, I will tell you how to generate more advanced data structures, so that we can add comments to our blog articles. (Still to come future: How to setup a server and deploy to it, tips on working with your code, exploring the rails structure, AJAX, and RSS feeds)

The seed of the conference was idea by Nils Christian Haugen and Aslak Hellesøy to have a whole day devoted to open spaces. Meanwhile, I had been experimenting with “lightning talks” on Oslo XP meetup, a user group that meets in Oslo every month. The inception of the open spaces conference was delayed over the summer, and towards the end of the summer, Trond Pedersen and myself were discussing the success of the Oslo XP meetup lightning talks over a beer. The more we thought about it, the more it seemed natural: We need a whole day devoted to lighting talks. Meanwhile, Simen Fure Jørgensen decided to start up Oslo Lean Meetup.

We tossed the ideas around on the smidig.no forum for a while, and Christian Hauknes noticed how disorganized we all were about it, and decided to make it all come together. Along the way, many enthusiasts have contributed. Without them, it would all still be a fantasy in the minds of a few people.

Finally, we all came together with a single vision: A two day conference for the community, by the community. We know that there are a lot of people with extremely valuable experience who seldom get heard. Instead, conferences focus on big names that tend to overshadow the participants.

We hope that Smidig 2007 will be different. Both days of the conference are devoted to ways to get the participants to learn from each other. Open spaces workshops allows for in depth exploration of topics and experiences, while Lightning Talks, a presentation form that limits all talks to 10 minutes, allows for a wide range of point of view and experience.

Over 50 speakers have already signed up. For a conference where we expect a total of not much more than 200 participants, this is great. I’m overwhelmed by the great support of the business community. Over 20 sponsors have signed up, ensuring that we won’t go broke in the process of pulling together this conference. We have the budget to pull of a spectacular conference dinner, video recording of the whole event, and the most interesting venue in all of Oslo.

There are still a lot of things that could be improved. If you read this blog, and you would like to play around with the Rails-based conference application, organize a conference dinner, organize an open space conference, write about the conference, discuss experiences using agile principles on the forum, or help move chairs and table around during the conference, we would like your help. Or even better: If you yourself see room for improvement. Send an email to the conference mailing list to get in touch with us.

I have always been impressed by the insights of Oslo software professionals. I am looking forward to hearing a dozens of them speak in November.

Click here to view on YouTube

The problem is that a blind taste test is not the same as drinking a whole bottle. People prefer sweet tastes when they just take a sip, but not when they want to finish the glass.

A lot of visually oriented software development tools are similar: They have been optimized for a 30 minute demo in front of a crowded auditorium. Sadly, many of these products are an active obstacle when you want to “finish the glass”, that is, deliver working software into production.

Ruby on Rails is different: It looks great in a demo, but it take the whole software development life cycle into account. These two facts put together is why I recommend it so much these days.
(Shameless plug: If you’re located in Oslo, and would like an introduction to Ruby on Rails: Feel free to get in contact with me).

For a full tutorial on Rails, I recommend Rolling with Ruby on [Instant]Rails, by Curt Hibbs and Bill Walton.

The Demonstration

This week, I showed a client how to use Ruby on Rails to get started developing web applications. I felt the workshop was a fruitful one. None of the people in the room (except me, of course) had any experience with Ruby on Rails or Ruby, and some of the audience had not worked with programming at all for several years.

In spite of this, everyone was able to understand how the application worked, and how everything fits together. This is what I find to be so fun about demonstrating Rails: There are no hidden tricks. I can install everything on a provided computer and I can explain how all the pieces fit together. I can explain how to address deployment, database upgrades, layout issues, AJAX, REST-webservices, security, and scalability. This is not a magic trick to be waved in front of an audience and they quickly hide behind your back.

In a matter of a few hours, we were able to demonstrate, discuss and explain:

• Install the necessary software (Ruby, MySQL, and Rails itself via gem install rails. Alternatively, we could’ve used InstantRails)
• Create an explore a working, simple “hello world” web application
• Use Ruby on Rails’s Migration and Scaffold to create a database table (ruby script/generate model service_provider name:string description:text registration_date:date) and the web pages to create, display, update, and delete entries in the table (ruby script/generate scaffold service_provider). Rails comes with scripts to create the tables (rake db:migrate), and load pregenerated (but editable) test data (rake db:fixtures:load).
• Create and explore a bidirectional one-to-many relationship between ServiceProviders and Customers with has_many and belongs_to
• Implement a mock-login scheme using sessions. Our login-action lists all the service_providers (using a select list). Yeah, I know it’s lame, but implementing passwords takes time, and doesn’t really prove anything.
• Restrict which Customers a ServiceProvider can see and modify (by using a before_filter and using session[:service_provider].customers.find instead of Customers.find, session[:service_provider].customers.delete instead of Customers.delete and session[:service_provider].customers.build instead of Customers.new)
• Implement some validation rules
• Explore (but sadly, not demonstrate) deployment options using Capistrano