Plugin for Login and Authentication

The RESTful login plugin from Rick Olson is a handful method to implement a user login mechanism.

Some links below for future reference.

RESTful Authentication

To install this plugin, use command

ruby script/plugin install 
http://svn.techno-weenie.net/projects/plugins/restful_authentication/

For single id sign on, use OpenID authentication

OpenID Authentication

Ruby's block

Ruby's block always make a developer like me who is being with typed language for long time confused.

In Ruby, there are some methods called Iterators like times, each, map, upto and downto and some objects called Enumerable objects like array, hash and range which contain many Iterator methods. The common feature of these methods is that they are all interacted with some custom codes.

A group of these codes for a method is called "a block".

For example:

[1,2,3].map {|x| x*x}

• [1,2,3] is an Enumerable object(an Array)


• "map" is an Iterator(method) which will transverse all elements in the Array


• {|x| x*x} is a block provide by user for callback from "map" method


• a "yield" method is provided in "map" to call block code

So, block is a group of custom codes waiting for Iterator method to call. Each time when a "yield" is met, block is called.

Here is a very simple example about an Iterator method call "twice".

def twice
yield
yield
end

When you call this iterator, it just yield twice that means the caller's block will be invoked twice.

twice {puts "hello"}

output: hello hello.

Of course you can pass value from Iterator method to yield block.

def sequence(n, m, c)
  i = 0
  while(i < n) # Loop n times
    #Invoke the block and pass a value to it
    yield m*i + c 
    i += 1 # Increment i each time
  end
end

The Iterator method is invoked by: 
  sequence(3, 5, 1) {|y| puts y }

The passing block parameter ({|y| puts y}) can be explicitly declared in the Iterator. Once it is declared, "call" method is used to invoke the block instead of "yield".

def sequence(n, m, c, &b)
  i = 0
  while(i < n) # Loop n times
    #Invoke the block and pass a value to it
    b.call(m*i + c)
    i += 1 # Increment i each time
  end
end

The Iterator method is invoked by: 
  sequence(3, 5, 1) {|y| puts y }
  # Note that the block is still passed outside of the parentheses

Render a collection

Very often we want to list a collection of data in front HTML page.

Let's say we have an animal collection. Each record of this collection contains animal Specie, Age, Weight and Risk. As you can imagine, the list is retrieved by

animal_controller.rb

Class AnimalController < ApplicationController
  ...
  def show
    @animals = Animal.find :all
  end
  ...
end

Now, how shuold we render the collection?

Usually we use 'for each' against the collection to render the table:

show.html.erb

<table>
  <tr><td>Specie</td>
      <td>Age</td>
      <td>Weight</td>
      <td>Risk</td>
  </tr>
  <tr>
  <% for each @animals do |animal| %>
      <td><%= h(animal.specie) %></td>
      <td><%= h(animal.age) %></td>
      <td><%= h(animal.weight) %></td>
      <td><%= h(animal.risk) %></td>
  <% end %>
  </tr>
</table>

But there is a better solution with a bonus feature, a counter of records. Once you are used to this solution, you most likely will not turn back.

The solution is to use partial with :collection function and key is NAMING CONVENTION.

The collection partial is passed in by this way:

show.html.erb

<table>
  <tr><td>Specie</td>
      <td>Age</td>
      <td>Weight</td>
      <td>Risk</td>
  </tr>
  <% render :partial => 'animal', :collection => @animals %>
</table>

Partial's name 'animal' will be passed into partial as a varible. It represents one record in the collection. So, 'animal' can be used to reference one record in the collection.

Here is the partial:

_animal.html.erb

  <tr>
      <td><%= h(animal.specie) %></td>
      <td><%= h(animal.age) %></td>
      <td><%= h(animal.weight) %></td>
      <td><%= h(animal.risk) %></td>
  </tr>

You can also add a new column to count the rows. There is a 0 based counter avaiable in partial. By naming convention, the counter variable is called animal_counter (partial-name_counter).

_animal.html.erb

  <tr> 
      <td><%= animal_counter %></td>
      ...
  </tr>

Don't forget using h(...) function to sanitize your passed in variable.

Now I can access the WEBrick server

As you know you can access a Rails project via browser by calling

 http://localhost:3000/.../... 

But when I try to access this project from other computers by calling

http://[computer_name]:3000/.../...

or

http://[ip_address]:3000/.../...

, IE or FireFox just can't reach the web page.

This problem bothered me for a while. I read some articles about how WEBrick works but did find how to make visible to other computers.

Today I have to ask helps from Rails community and finally found the solution. There is nothing to with how to config the WEBrick. It is simple as this:

Ruby script/server -b [ip_address] -p [port]

Now I can access the pages from other computers. Pretty happy.

Polymorphic Raccoon

Yesterday night, my mom was terribly scared by a raccoon. She said it made a funny face when she was watching TV.

This brought a question to me. Is raccoon offensive? If not, why was my mom scared?

So, if I create an label and attach it to anything (I mean anything, not just animals) which are offensive, my mom should NOT be scared.

Since the label is going to be attached to ANYTHING, it brings me an association dilemma. If a Offend label is attached to Raccoon class, an association from Raccoon to Offend is established. If another Offend label is attached to Dog class, another association to Offend is also established. So, Offend must hold both 'foreign keys' to Man and Dog. But each record of Offend class always has one foreign key with Null value. For example, if Offend record 1 points to Raccoon, the foreign key to Dog must be Null. Vise versa.

In Ruby On Rails, 'polymorphic has_many association' can solve the problem. 'polymorphic has_many association' hooks a particular class to any kind and number of sources classes. These source classes may not be related.

First, let's define an INTERFACE called offensive (you can use any name) and declare it is polymorphic.

Second, let's create a Offend class which will be attached as a label to other classes. Then, we make Offend class belong to the INTERFACE.

offend.rb

class Offend < ActiveRecord::BASE
 belongs_to :offensive, :polymorphic => true
end

Third, create two columns in table offends: offensive_id and offensive_type

002_create_offends.rb

class CreateOffends < AcriveRecord::Migration
 self.up
  create_table :offends do |t|
  t.column :offensive_level, :integer
  t.column :offensive_id, :integer
  t.column :offensive_type, :string
  t.timestamps
 end

 self.down
  drop_table :offends
 end
end

In Rails 2.0+, a new macro style method 'references' is introduced to automatically create the INTERFACE's id and type.

002_create_offends.rb

class CreateOffends < AcriveRecord::Migration
self.up
 create_table :offends do |t|
  t.column :offensive_level, :integer
  t.references :offensive, polymorphic => true
  t.timestamps
 end

 self.down
  drop_table :offends
 end
end

But I found only offensive_id was generated, not offensive_type. The INTERFACES's type field is used to hold the classes' type of which the Offend class will be attached to, such as Raccoon or Dog. So more research on 'references' method is needed in the future.

Now we are ready to attach this class to any source classes.

First, simply declare has_many offends via offensive INTERFACE.

dog.rb

class Dog < ActiveRecord::BASE
 has_many :offends, :as => :offensive
 ...
end

raccoon.rb

class Raccoon < ActiveRecord::BASE
 has_many :offends, :as => :offensive
 ...
end

Second, create a Offend object and update its :offensive attribute by passing the source objects (like instance of Dog or Raccoon) in.

>>d = Dog.find :first
>>r = Raccoon.find :first
>>o1 = Offend.new offensive_level => 3
>>o2 = Offend.new offensive_level => 5
>>o1.update_attribute(:offensive, d)
>>o2.update_attribute(:offensive, r)
 
 
 
Notice, you can't do o1.save. It won't work. o1.update_attribute(:offensive, d) will automatically save the newly created o1 into database and set o1.offensive_type to Dog.

Now we can see, by attaching the class Offend, Raccoon is more dangerous then Dog.

I am a VIP

A problem I found is how Model class inheritance reflects in table relationship. When I saw the Single-Table Inheritance (STI) introduced by Martin Fowler a couple of years ago, I thought it was really stupid.

The whole idea of STI is simple: include all super/sub classes' attributes in one big fat single table and use an extra column (may be called 'type') to distinguish different type of classes.

But the default rails way is STI. :(

Now I have a Model class User and want to have another Model class called VIPUser which is a subclass of User. VIPUser has a new attribute called vip_number which User doesn't have.

OK, let's do the magic.

First, create a VIPUser Model

ruby script/generate model VIPModel
  
      exists  app/models/
      exists  test/unit/
      exists  test/fixtures/
      create  app/models/vip_user.rb
      create  test/unit/vip_user_test.rb
      create  test/fixtures/vip_users.yml
      exists  db/migrate
      create  db/migrate/008_create_vip_users.rb

Second, edit the migration script for VIPUser

008_create_vip_users.rb
class CreateVipUser < ActiveRecord::Migration
  def self.up
    add_column :users, :vip_number, :integer, :default => 0
    add_column :users, :type, :string
  end

  def self.down
    remove_column :users, :vip_number
    remove_column :users, :type
  end
end

Notice that two new columns are created in the users table (which is for Model class User). One is the attribute of VIPUser, 'vip_number' and another is 'type' which is used to distinguish the type of classes.

If you've already had a column called 'type' or you don't like the name, you can use any other names and later declare it in VIPUser Model class.

vip_user.rb
  set_inheritance_column 'object_type'

Third, make VIPUser a subclass of User

vip_user.rb
class VIPUser < User
  ...
end

That is it!

Now if you create a new VIPUser, you will see Rails automatically populate a string 'VIPUser' in type field.

>>VIPUser.new
VIPUser id: nil, 
user_name: nil, 
status: "active", 
created_at: nil, 
updated_at: nil, 
vip_number: 0, 
type: "VIPUser"

No, you can't delete accounts!

In many cases, bank managers ask you to keep an account information even it is closed or removed. Usually we keep the record in database but mark it by a flag column like 'delete_at' or 'status'.

To provent the false deletion, a method is registered to callback before_destroy.

class Account < ActiveRecord::BASE
  ...

  protected
  
  def before_destroy
    update_attribute(:delete_at, Time.now) and return false
  end
end

Notice that return false is very important. It halts the execution of the further deletion action.

Also notice that delete and delete_all ActiveRecord model methods will bypass the before_destroy callback methods.

for example:

>>account=Account.find 1
>>account.destroy  #this will trigger the callback

>>account=Account.find 1
>>Account.delete(account)  #this will not trigger the callback