People often post on user boards – “I want to learn php which framework should I use?”. If you’re going about learning a language by using a framework written in that language – stay away from full stack frameworks. You’ll have a much enjoyable time using a simpler more “declarative” framework.

One solution is to show the user an easy math problem: 2 + three =. While this is easier for the user, a quick Google search will give the spammer the answer.

Today I saw another alternative for captchas in Hasin’s blog post Time to put those FUCKING captchas to an end. His alternative captcha theory is to show you an easily identified object, a tree or statue, and have you say what it is. Spammer’s solution: run the image through Google’s photo search. The third example, where the picture asks “There are two ___” and then shows two squares and three triangles, did stump Google. But this image would not be difficult to parse and answer.

The current captcha system is painful, tedious, and can be comical at times, but it does knock off a majority of the spammers.

Custom Date Formatting

There are two main theories to Date Formatting. Building a time_format initializer or adding date formats to your locales file. Since date formats differ between regions it makes sense to place these formats in your locales file.

Open up config/locales/en.yml, app/view/posts/show.html.erb, and app/view/posts/index.html.erb and make these changes. In locales file, the format named “default” will be used if no format is specified. In the view file, those are L’s that have been added prior to the dates. L is a default rails helper method for localize and will apply the localization for that data in our case a timestamp. You can add as many differing formats as you’d like. You can call these by using the following code

<%= l Time.now, :format => :awesome %>

A cheat sheet of all ruby date formats can be found here. If you would like more information on locale files, Ruby on Rails has a good guide on it.

Usernames

Adding usernames is a breeze with Devise. The first step to is create a migration to add the column.
$rails g migration addUsernameToUser username:string
Open up the generated migration and make these changes then run the migration.
Since we plan to allow users to login using their username we’ve made it a unique key, the database will not allow more than 1 User to have the same username. Now that the column is created, modify the User model to allow editing and validation of username. We will also make sure that Devise is validating data in the forms. You can see the changes here, user.rb

Now that our model and database are set to handle usernames, we have to make sure our views can handle them. To do this we need to extend the default Devise views. Run the following commands and then edit the files as seen here.
$ rails generate devise:views
For more information about this as well as how to let user recover their passwords using username or email please see the Devise wiki.
Now that we can edit, login and register with usernames, lets display them on our page. Edit post show and post index templates as seen here.

Check in next week were we will add comments to the posts.

git clone git@github.com:baileylo/blog.git
git checkout -b blogCreated 0ba92371c2998caf362827987a82050708e9cd25


First add devise to your gemfile, gem “Devise”. Then run the follow commands:

$ bundle install
$ rails generate devise:install

This will install the Devise gem and set up the Devise modules. You will be prompted for 3 steps:

Some setup you must do manually if you haven't yet:

  1. Setup default url options for your specific environment. Here is an
     example of development environment:

       config.action_mailer.default_url_options = { :host => 'localhost:3000' }

     This is a required Rails configuration. In production it must be the
     actual host of your application

  2. Ensure you have defined root_url to *something* in your config/routes.rb.
     For example:

       root :to => "home#index"

  3. Ensure you have flash messages in app/views/layouts/application.html.erb.
     For example:

       <p class="notice"><%= notice %></p>
       <p class="alert"><%= alert %></p>

Do step 1, step 2 and 3 should already be done. Once you have completed these steps run:

$ rails generate devise user

Open up your user model(app/models/users.rb). You will see a comment at the top listing possible devise modules. You can add and remove these as you wish. For this tutorial we’ll only use: database_authenticatable, registerable, recoverable, rememberable, trackable. Save the changes, and run:

$ rake db:migrate
Now if you run “rake routes” you will see a series of /users/ routes setup automatically by Devise. Open up your application template, app/views/layout/application.html.erb and add the following code:

<div class="user-auth-nav" style="float:right">
  <% if user_signed_in? %>
  <%= link_to('Edit registration', edit_user_registration_path) %> | 
  <%= link_to('Logout', destroy_user_session_path) %> 
  <% else %>
  <%= link_to('Login', new_user_session_path)  %> | 
  <%= link_to('Register', new_user_registration_path)  %>
  <% end %>
</div>

Restart your rails server, and then reload your page. You should see in the top right Login and Register links. Feel free to create an account and play around with Devise’s built in authentication and user validation.

Now we need to associate a specific author with a specific post. To do this will use another migration:

$ rails generate migrate addUserIdToPosts user_id:integer
$ rake db:migrate


Rails migration generator will automatically read the migration name and realize that we’re adding the UserId column To the Posts table. Now we need to make the relationships between the models in ruby. Open up the user model(app/models/user.rb) and add “has_many :posts” within the class definition. Now open the posts model (app/models/post.rb) and add “belongs_to :user” within the class definition.
diff

So far now we’ve created user authentication system and added user to a post. Open your posts controller (app/controllers/posts_controller.rb) and add the following line at the top of your class, but inside the class definition
before_filter :authenticate_user!, nly => [:edit, :update, :destroy, :create, :new]
This will apply Devise’s built in function authenticate_user! When the actions edit, update, create, new, and destroy are called. It will effectively require the user to be logged in to access these actions.

Prior to a post being saved, we’re going to want to set the “poster” to be the user who is currently signed in. Devise provides the current_user helper which allows you access to the logged in user’s User object. Change the “create” action in the posts controller to look like this.

@post = Post.new(params[:post])
@post.user = current_user

diff

This will assign the currently logged in user as the user for the post. Lets clean up the views a little big. Change your posts index.html.erb and show.html.erb files to look like this, app/views/posts/.
diff

You may be getting error that reads: “undefined method `email’ for nil:NilClass“. These blogs were posted prior to having added the user migration. You can add an if statement to skip the user data when a Post doesn’t have a related User Object. But lets make a migration, run the following command
$ rails g migration insertUserInAllPosts

Open up the generated migration, and make the following changes . We named the migration “insertUserInAllPosts”, the name is up to you. It is nice to have descriptive names for migrations; in the future you will waste less time figuring out what the migration does if it has a good name.
diff

You may have noticed that we have removed the links to edit posts for other users, but they can still edit posts if they go directly to the url. To fix this we’ll use another “before_filter”. Open up the posts controller, app/controllers/post_controller.rb, and make the following changes:
diff

Now you have a full authorized blog. Come back next week to see user customizations.

The Blog:
First lets create our rails application and come up with some basic starting blocks for our blog.
$ rails new blog
$ cd blog
$ rails generate scaffold post title:string body:text
$ rake db:migrate
$ rails -s

The first two commands create the base rails framework. The next command is where you see a lot of the benefit of using ruby on rails. It automatically created the migration files, model files, controller files, and view files for our new database object called “Post”.
Migrations are how rails tracks schema changes in your database. You can migrate the database up to a latest migration or roll down to a previous migration. Rake db:migrate is the command to make the schema changes for the latest migration. Rails -s creates a simple webbrick server; this server is good for development, but not production.

You should now be able to goto localhost:3000 where you will be greeted by a friend rails page. Of course you probably don’t want your users to see this page so remove public/index.html.erb and add a new route, ‘root :to => “posts#show” to your configs.rb, seen here.

Once you reload your homepage you should see the friendly rails scaffolding. Feel free to create your first post!

Setting Up Authors on Your Blog

I’ve decided I want to blog more. Rather than just thinking about doing it, I’m starting right now. I will be posting on this blog once a day / once a week for all of 2011.

I know it won’t be easy, but it might be fun, inspiring, awesome and wonderful. Therefore I’m promising to make use of The DailyPost, and the community of other bloggers with similiar goals, to help me along the way, including asking for help when I need it and encouraging others when I can.

If you already read my blog, I hope you’ll encourage me with comments and likes, and good will along the way.

Signed,

1. Load the code base and figure out which classes were default to php and which were my own.
2. Figure out what file each class was declared in
3. Store the data to a flat file for later reading.

1. Figuring Out Whose Class It Is:

To figure out which classes were mind and which were natively part of php is a rather simple task using the get_declared_classes() function I was able to determine which classes were native to php. After completely loading the code base, I ran the function again. The difference of the initial run and the second run is my defined classes.

2. Where Was It Declared:

To figure out where each class is declared you use PHP reflection.

<?php

foreach($class_list as $classname) {
    $reflector = new ReflectionClass($classname);
    $ini_config_data[strtolower($classname)] = $reflector->getFileName();
}

?>

3. How To Store It:

Incase you couldn’t guess I used an ini file. PHP has native ini parsing to array (parse_ini_file) so the read is extremely simple. The write ends up being rather simple as well.

<?php
$fp = fopen('object_map.ini', 'w');

foreach($ini_config_data as $class => $filename) {
    $write = $class . ' = ' . $filename . PHP_EOL;
    fwrite($fp, $write, strlen($write));
}

fclose($fp);
?>

Writing __autoload:

The autoload function is very straight forward, it takes 1 parameter the name of the class to load. We must look this up from are ini array and load it. The code could look like this:

<?php
$model_object = parse_ini_file('object_map.ini');
function __autoload($class_name) {
    global $model_object;
    $class_name = strtolower($class_name);
    if (!isset($model_object[$class_name])) {
        exit('invalid class name');
    }
    
    require_once($model_object[$class_name]);
}
?>

Now after I create a new model, I simply rerun the script and I’m good to go.

There’s not really much else to it.


create table `user`(
    `id` INT(10) PRIMARY KEY,
    `name` VARCHAR(25)
);
create table `message` (
    `id` INT(10) PRIMARY KEY,
    `author_user_id` INT(10),
    `recipient_user_id` INT(10),
    `subject` VARCHAR(250)
);


To create the correct ORM relations use the following ruby code:

class Message < ActiveRecord::Base
    belongs_to :author, :class_name => "User", :foreign_key => "author_user_id"
    belongs_to :recipient, :class_name => "User", :foreign_key => "recipient_user_id"
end


With the above code you can access user data via

<%= @message.author.name %>


$ mkdir forums
$ git init
$ git clone git://github.com/baileylo/login_app.git forums
$ cd forums
$ rake db:migrate
$ rails -s


Feel free to verify that everything is working, you should be able to register and login at /users.

The Backend

Rails has reserved “thread” has a model name so this will create a weird model name but the other two model names are straight forward: Board, Conversation, Comment.

Board is a set of boards, groupings of conversations. Conversation, probably more commonly referred to as “Thread”, is list of Comments made by users. In our forum we’ll keep it simple, A Board will contain only a name and an id, a Conversation will belong to a board. A Conversation will have a title and a creating user. Comments will have only a body a posting user and a reference to the conversation they belong to.


$ rails g scaffold board id:integer title:string
$ rails g scaffold conversation id:integer title:string board_id:integer user_id:integer
$ rails g scaffold comment id:integer user_id:integer conversation_id:integer body:text


This created all the controllers, views, models, and migration files needed. Open up the three migration files created, and edit them to look as follows.

class CreateBoards < ActiveRecord::Migration
  def self.up
    create_table :boards do |t|
      t.integer :id
      t.string :title, :limit => 50

      t.timestamps
    end
    
  end

  def self.down
    drop_table :boards
  end
end

class CreateComments < ActiveRecord::Migration
  def self.up
    create_table :comments do |t|
      t.integer :id
      t.integer :user_id
      t.integer :conversation_id
      t.text :body

      t.timestamps
    end
    add_index :comments, :conversation_id
    add_index :comments, :user_id
  end

  def self.down
    drop_table :comments
  end
end

class CreateConversations < ActiveRecord::Migration
  def self.up
    create_table :conversations do |t|
      t.integer :id
      t.string :title, :limit => 50
      t.integer :board_id
      t.integer :user_id

      t.timestamps
    end
    add_index :conversations, :board_id
    add_index :conversations, :user_id
  end

  def self.down
    drop_table :conversations
  end
end

These changes add indexes to our Conversations and Comments tables. These will add a much needed performance boost when querying the database. They also added size limitations to board.title and conversation.title of 50 characters.

Now create the database tables by running:


$ rake db:migrate


Some Quick Backend Additions

Feel free to browse around the site, you’ll notice all the forms work correctly, but none of the objects are linked together. To tell active record that these models are linked we must edit the Model Classes.
Open up your newly created model classes and edit them to look like this:

class Board < ActiveRecord::Base
  has_many :conversations
end

class Comment < ActiveRecord::Base
  belongs_to :conversation
  belongs_to :user
  validates_presence_of :body
end

class Conversation < ActiveRecord::Base
  has_many :comments
  belongs_to :user
  belongs_to :board
  validates_presence_of :title
end

In this we see two very important ideas. We’ve added form validation as well as ORM hooks that define relationships between our models. In board.rb and conversation.rb we added has_many :conversations and has_many :comments, respectively, this informs Rails these are 1 to many relationships. You can see the rails docs for has_many here. This makes the relationship from one conversation to many comments. In conversation.rb and comments.rb you can see the belongs_to function, this function tells rails that these objects belong to another specific object, you can see the docs for belongs_to here.
validates_presence_of is called when a save, update, or create are called on an object. This function makes sure that there is data stored in these member variables. We specified that conversation.title and comment.body must be required, we don’t want any empty posts. Board.title was purposefully skipped, it is not for general use.

If you navigate to your conversations page: http://localhost:3000/conversations and try to create a message, not including a title, you will get a nice error saying that it is a required field. You will how ever notice that you can make this field as long as you like even though we specified it should only be 50 characters long. Lets fix this, add the following line of code to your conversation.rb file:


validates_length_of :title, :maximum=>50


If you try again you will see an error message stating that the “the input must be less than 50 characters”.

If you’ve created any data, you may want to clean it up now, it may cause problems later in this demonstration.

Routes!

Now that we have the backend in order, lets create the routes needed to use this message board. Open up your config/routes.rb file and change it to look like this:

LoginApp::Application.routes.draw do

  resources :boards do 
    resources :conversations
  end

  root :to => "boards#index"

  resources :users, :user_sessions
  match 'login' => 'user_sessions#new', :as => :login
  match 'logout' => 'user_sessions#destroy', :as => :logout
end

Delete your public/index.html file, it’s no longer needed.

Now localhost:3000/ will display a list of your Boards, instead of the rails information page.

In your console type:


$ rake routes


This is a list of every url that your app can handle, the most important are the top few. We’ve now created a url hierarchy. All of a conversations will be listed by /boards/:board_id/conversations/:id.

Jumping into the view

Our site looks okay, but lets try and spiff it up a bit. Open up your views/layouts/index.html and change it to look like:

<!DOCTYPE html>
<html>
<head>
  <title>Rails Message Boards</title>
  <%= stylesheet_link_tag :all %>
  <%= javascript_include_tag :defaults %>
  <%= csrf_meta_tag %>
</head>
<body>

    <div id="wrapper">
        <div id="top_nav">
            <h1><%= image_tag("rails.png", :size => '50x50') %> Rails Boards</h1>
            
            <% if current_user %>
            <%= link_to "Edit Profile", edit_user_path(current_user.id)%> |
            <%= link_to "Logout", :logout%>
            <% else %>
            <%= link_to "Register", new_user_path%> | 
            <%= link_to "Login", :login %>
            <% end %>
            <div class="bclear"></div>
        </div>
        
    
        <div id="content">
            <%= yield %>
        </div>

        <div id="footer">

        </div>
    </div>
</body>
</html>

Create a new file in public/stylesheets called style.css and copy this style sheet, http://gist.github.com/627780

.

At localhost:3000 you should be greeted by a much friendlier page:

If you haven’t created a board yet, feel free to create one now using the “Create Board” Link at the bottom of the page. You can put in you own ID if you want, if you leave it blank rails will auto increment the id.

Lets fix up that homepage a bit and make it look slightly more professional. Open up views/boards/index.html, and change it to look like this:

<h1 id="page_title">Message Boards</h1>
<p id="notice"><%= notice %></p>
<table>
  <tr>
    <th align="left">Title</th>
  </tr>

<% @boards.each do |board| %>
  <tr>
    <td><%= link_to board.title, board %></td>
  </tr>
<% end %>
</table>

Now that our landing page looks decent, lets see what happens when we view our message board:

Not what anybody envisions a messageboard to be looking like, lets make some quick cosmetic changes before moving into the controller. Open up app/views/boards/show.html.erb and make it the following changes:

<h1 id="page_title"><%= @board.title %></h1>
<p id="notice"><%= notice %></p>
<%= link_to 'Rails Boards', boards_path %> &gt; <%= link_to @board.title, @board %> <br />
<%= link_to 'Post New Message', new_board_conversation_url(@board) %>

As you can see here we added a “Post New Message” link, the url function did not come out of thin air, if you run rake routes again. You’ll see there is a path named “new_board_conversation”, you can use any of those as a url by appending _url or _path to them.

If you click on the link to post new message you’ll get “No Routes Matches” error. We’ll fix that in a minute, but first lets make some adjustments to our conversation controller, open up app/controllers/conversation.rb and make the follow changes:

class ConversationsController < ApplicationController
  before_filter :load_board
  
  # GET /conversations
  # GET /conversations.xml
  def index
    @conversations = Conversation.all

    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render :xml => @conversations }
    end
  end

  # CODE REMOVED FOR CLARITY SAKE
  
  private
  
  def load_board
    if Board.exists?(params[:board_id])
      @board = Board.find(params[:board_id]);
    end
              
    unless @board
      redirect_to(boards_path, :notice =>"Please specify a valid board")
    end
  end
end

We added a private function that tries to load a Board off a passed in parameter. This function will be called on any page that goes through this controller.

Modify AuthLogic

If you have tried to login you may have noticed that we skipped a step. The login, logout, and register functions are not exactly tied to our application. To fix this we need to correct links in the views and redirect the controllers. While we’re doing this it will be a good time to remove functions that the app won’t be using. Open up app/controllers/users_controller.rb and edit it to look like so:

class UsersController < ApplicationController

  # GET /users/1
  def show
    @user = User.find(params[:id])
  end

  # GET /users/new
  def new    
    @user = User.new
    
    if current_user
      redirect_to(homepage_url, :notice => 'Already registered')
    end
  end

  # GET /users/1/edit
  def edit
    is_user
  end

  # POST /users
  # POST /users.xml
  def create
    @user = User.new(params[:user])
    @user_session = UserSession.new(params[:user])

    respond_to do |format|
      if @user.save && @user_session.save
        format.html { redirect_to(homepage_url, :notice => 'Registration successfull.') }
      else
        format.html { render :action => "new" }
      end
    end
  end

  # PUT /users/1
  def update
    is_user

    respond_to do |format|
      if @user.update_attributes(params[:user])
        format.html { redirect_to(@user, :notice => 'User was successfully updated.') }
      else
        format.html { render :action => "edit" }
      end
    end
  end
  
  private
  
  def is_user
    if User.exists?(params[:id])
      @user = User.find(params[:id]);
      if !current_user || current_user.id != @user.id
        redirect_to(homepage_url, :notice =>"You do not have access to that page")
      end
    else
      redirect_to(homepage_url, :notice =>"You do not have access to that page")
    end
  end

end

In this controller we added a function is_user. This function determines if the user is logged in and they are the correct user to be viewing specific pages. We also changed redirect urls to the site homepage and removed a lot of unused code. Now lets update our User View: We’ll have to change the links on all the pages as well as display less confidential information on the Profile page.

<h1 id="page_title">Edit Your Profile</h1>

<%= render 'form' %>

<%= link_to 'Show', @user %> |
<%= link_to 'Back', homepage_url %>

<h1 id="page_title">Registration</h1>

<%= render 'form' %>

<%= link_to 'Back', homepage_url %>

<h1 id="page_title"><%= @user.username %>'s Profile</h1>
<p id="notice"><%= notice %></p>

<p>
  <b>Username:</b>
  <%= @user.username %>
</p>

<p>
  <b>Email:</b>
  <%= @user.email %>
</p>


<%= link_to 'Rails Boards', homepage_url %>

Now we just have to fix the Login view and the login/logout controller. These files need to have some cosmetic changes and fix issues with redirects open up app/views/user_sessions/new.html.erb and app/controllers/user_sessions_controller.rb and edit them to look like the following:

<h1 id="page_title">Login</h1>

<%= render 'form' %>

<%= link_to 'Back', homepage_url %>

class UserSessionsController < ApplicationController

  # GET /user_sessions/new
  def new
    @user_session = UserSession.new
  end

  # POST /user_sessions
  def create
    @user_session = UserSession.new(params[:user_session])

    if @user_session.save
      redirect_to(homepage_url, :notice => 'Login Successful')
    else
      render :action => "new" 
    end
  end

  # DELETE /user_sessions/1
  def destroy
    @user_session = UserSession.find
    @user_session.destroy

    redirect_to(homepage_url, :notice => 'Goodbye!')
  end
end

Now we just changed all the automatic form rerouting to point to our default homepage, added some basic styling, and changed the links in the site to point to more logical places. Lets create some content

Creating a New Post

There are four parts to our new posts: author, board, title, body. Author will be determined by the user_session, board will be determine through the URL, what our form needs to get from the user is title and body. We must modify the Conversation controller to create a Comment object which we can use in the view.
Open up app/controllers/conversation.rb and modify create and new functions to look like this:

# GET /conversations/new
def new
  @conversation = Conversation.new
  @comment = @conversation.comments.build

  respond_to do |format|
    format.html # new.html.erb
  end
end

# POST /conversations
def create
  @conversation = Conversation.new(params[:conversation])
  @comment = @conversation.comments.build(params[:comment])
  @conversation.user_id  = @comment.user_id = current_user.id
  @conversation.board = @board
  
  respond_to do |format|
    if current_user && @conversation.save
      format.html { redirect_to(board_path(@board), :notice => 'Your Post was created') }
    else
      format.html { render :action => "new" }
    end
  end
end

The build function was automatically created when we used has_many :comments in the model, it creates an unsaved object using default values. In the create function we’ve added the board and author variable assignment, we also check to see if the user is logged in before we save.

if current_user && @conversation.save

We create @comment in both places for simplicity. Both of these function use the same view, create if there is an error and new by default, thus we need the same variables in scope. In the create function we pass in params[:comment] to build, this will build a Comment object with any data passed in the comment parameter.

Now lets setup our views, change app/views/conversations/index.html.erb, app/views/conversations/_form.html.erb to look like this:

<%= form_for(@conversation, :url => board_conversations_path) do |f| %>
  <% if @conversation.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@conversation.errors.count, "error") %> prohibited this conversation from being saved:</h2>

      <ul>
      <% @conversation.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <div class="field">
    <%= f.label :title %><br />
    <%= f.text_field :title %>
  </div>

  <%= fields_for(@comment) do |cf|%>
  <div class="field">
    <%= cf.label :body %><br />
    <%= cf.text_area(:body, :size => "60x10")%>
  </div>
  <% end %>
  

  <div class="actions">
    <%= f.submit :as => "Create Post"%>
  </div>
<% end %>

<h1 id="page_title">New conversation</h1>
<%= link_to @board.title, @board %>

<%= render 'form' %>

<%= link_to @board.title, @board %>

The changes to new.html.erb are fairy straight forward. We added an id to the h1 tag, and changed the link to display the name of the current table and link to the current table. We modified_form.html.erb pretty heavily, we removed alot of the input fields that will be assigned in the controller. We also modified the error printing at the top to include any errors from @comment. fields_for works like form_for but does not create a new form tag. This allows us to create fields that are related to other objects.

Lets create our first post. When you’re done it should look something like this:

[img new_post.jpg]

Viewing Our Post

You may be wondering where your posts are? Clearly they’re in the database but they’re not showing up in our view. Lets fix that, open up app/views/boards/show.html.erb

<h1 id="page_title"><%= @board.title %></h1>
<p id="notice"><%= notice %></p>
<%= link_to 'Rails Boards', boards_path %> &gt; <%= link_to @board.title, @board %> <br />

<table>
  <tr>
    <th>Post / Author</th>
    <th>Last Reply</th>
    <th>Number of Replies</th>
  </tr>
<% @board.conversations.each do |conversation| %>
  <tr>
    <td>
      <%= link_to conversation.title, board_conversation_path(:board_id => @board, :id => conversation) %><br />
      <%= conversation.user.username %>
    </td>
    <td>
      <%= conversation.comments.find(:last).created_at %><br />
      by <%= conversation.comments.find(:last).user.username %>
    </td>
    <td>
      <%= conversation.comments.count - 1%>
    </td>
  </tr>
<% end %>
</table>
    

<%= link_to 'Post New Message', new_board_conversation_url(@board) %>

We display all the conversations in that board along with some basic meta data. Most of this code is rather straight forward, the link to uses one of the routes that can be easily found using $ rake routes . We use the find function which was also provided when we used has_many. We subtract one for the number of replies so that we do not count the post it self. But all in all this view is as straight forward as they come.

Now lets work on the message view itself. Open up app/views/conversation/show.html.erb and edit to look like this:

<%= link_to @conversation.board.title, @conversation.board%>
<p id="notice"><%= notice %></p>



<table>
  <tr>
    <th colspan="2"><%= @conversation.title %></th>
  </tr>
  <% @conversation.comments.each do |comment| %>
  <tr>
    <td style="width:25%;">
      <%= link_to comment.user.username, comment.user %> <br />
      Posted At <br />
      <%= comment.created_at%>
    </td>
    <td>
      <p><%=comment.body%></p>
    </td>
  </tr>
  <% end %>
</table>
<%= link_to 'Reply', reply_board_conversation_url(:board_id=>@board, :id=>@conversation)%> |
<%= link_to @conversation.board.title, @conversation.board%>

Once again nothing to exciting happening here, the more astute of you may have realized we created a url function that we don’t currently have mapped. Lets create that route, add


get '/boards/:board_id/conversations/:id/reply' => "conversations#reply", :as => :reply_board_conversation
post '/boards/:board_id/conversations/:id/reply' => "conversations#save_reply", :as => :reply_board_conversation


This will create two different url matches, one for GET requests and one for POST, one when the page is called and one when the form is submitted.
Lets got and create the reply and save_reply functions in the conversation controller, they should look fairly similar to the new and create functions, or like these:

  # GET /conversations/reply
  def reply
    @conversation = Conversation.find(params[:id])
    @comment = @conversation.comments.build
    
    respond_to do |format|
      format.html #reply.html.erb
    end
  end
  
  # POST /conversations/reply
  def save_reply
    if !current_user
      redirect_to(:login, :notice =>"Please login before posting")
      return 1;
    end
    
    if Conversation.exists?(params[:id])
      @conversation = Conversation.find(params[:id])
      @comment = @conversation.comments.build(params[:comment])
      @comment.user_id = current_user.id
    else
      redirect_to(boards_path, :notice =>"Please specify a valid board")
    end
        
    respond_to do |format|
      if current_user && @comment.save
        format.html { redirect_to(board_path(@board), :notice => 'Your reply was posted') }
      else
        format.html { render :action => "new" }
      end
    end
  end

Once again here nothing is too revolutionary. reply handles the page load. It creates a @conversation and @comment for use in the view to generate forms. The @conversation is loaded from the url, as is a @board. @comment is empty. save_reply handles POST requests, so form submissions. It verifies that the user is logged in and that the parent conversation exists. It then creates the comment from the conversation, assigns the user, and assigns the values passed in from the form. It saves the data and redirects the user to the board overview with a friendly reminder.

Reply function uses reply.html.erb as it’s view, since that hasn’t been created yet lets do that now. Create another file as well _reply_form.html.erb. They should look like this:

<%= form_for(@comment, :url => reply_board_conversation_url(:board_id=>@board, :id=>@conversation)) do |f| %>
  <% if @comment.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@comment.errors.count, "error") %> prohibited this reply from being saved:</h2>

      <ul>
      <% @comment.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <div class="field">
    <%= f.label :body %><br />
    <%= f.text_area(:body, :size => "60x10")%>
  </div>
  

  <div class="actions">
    <%= f.submit(:value => "Create Reply")%>
  </div>
<% end %>

<h1 id="page_title">Reply To <%= @conversation.title %></h1>
<%= link_to @board.title, @board %>

<%= render 'reply_form' %>

<%= link_to @board.title, @board %>

There is nothing we haven’t seen before in these files by themselves. Reply.html.erb includes _reply_form.html.erb you can tell this by the render statement, ‘reply_form’ is prepended with ‘_’ so you know it’s not a controller view. _reply_form.html.erb uses the same action as we saw to generate the url to this page, and only has a text area input field.

Feel free to try it now out now. The complete forum/message board should be working. If you have any questions feel free to leave a comment or view the working code base on my GitHub For Rails boards