gem vs plugin

Rails Plugins

Rails plugins are pieces of code that can be added to a Rails application on at the application level, and reside in the vendor/plugins folder of that application. Plugins are simple to install by simply typing:

syntax
script/plugin install plugin_name

from within the root directory or a Rails application. The main feature to plugins is that they install in each application, and are specific to that application.

Ruby Gems
Ruby gems are also pieces of ruby code that can be added to a system running Ruby, just as simply as adding plugins to an application:

syntax
gem install gem_name

However, gems are installed at a system level, which means that rather than being specific to a Rails application, like a plugin is, gems are available to all Rails applications that are running on the same system. In other words, you would install a gem on your web server, where it is available to all Rails applications running on that web server.

REST vs. CRUD

REpresentational State Transfer and describes resources (in our case URLs) on which we can perform actions. CRUD, which stands for Create, Read, Update, Delete, are the actions that we perform. Although, in Rails, REST and CRUD are bestest buddies, the two can work fine on their own. In fact, every time you have written a backend system that allows you to add, edit and delete items from the database, and a frontend that allows you to view those items, you have been working with CRUD.

Resources

You would be used to seeing Rails URLs that look something like /posts/view/2 – which roughly translates to “Please let me view the post with the id number 2″. RESTful resources are very similar, in that they have a controller and (maybe) and id. What they generally don’t have is an action, because it is inherent in the HTTP verb.

To make this work, the Rails team have defined a number of special methods in the controllers that define resources – in this case posts (the .xml bit will become clear in the next part).

Method Resource Verb Explanation
index /posts.xml GET Returns all items
show /posts/1.xml GET Return a single item with id = 1
create /posts.xml POST Create an item
update /posts/1.xml PUT Update item with id = 1
delete /posts/1.xml DELETE Delete item with id = 1

Ruby on Rails: Custom primary key in ActiveRecord

Replacing the default integer-based primary keys in model with a Custom primary-key.

The solution is to disable the id column and create a customized primary key column instead.

create_table :posts, :id => false do |t|
t.string :post_id, :limit => 36, :primary => true
end

In your Post model you should then set the name of this new primary key column.

class Post < ActiveRecord::Base
set_primary_key "uuid"
end

Rails MVC

The Model is the application object, the View is its screen presentation, and the controller defines the way the user interface react to user input. Before MVC, user interface designs tended to lump these objects together. MVC uncouples them to increase flexibility and reuse.

The browser makes a request

The web server (mongrel, WEBrick, etc.) receives the request. It uses routes to find out which controller to use: the default route pattern is “/controller/action/id” as defined in config/routes.rb.

Controllers do the work of parsing user requests, data submissions, cookies, sessions and the “browser stuff”.

Models are Ruby classes. They talk to the database, store and validate data, perform the business logic and otherwise do the heavy lifting.

Views are what the user sees: HTML, CSS, XML, Javascript, JSON. They’re the sales rep putting up flyers and collecting surveys, at the manager’s direction. Views are merely puppets reading what the controller gives them. They don’t know what happens in the back room.

HABTM Custom Join Table in RoR

has_and_belongs_to_many(association_id, options = {}, &extension) public
Specifies a many-to-many relationship with another class. This associates two classes via an intermediate join table. Unless the join table is explicitly specified as an option, it is guessed using the lexical order of the class names. So a join between Developer and Project will give the default join table name of "developers_projects" because "D" outranks "P". Note that this precedence is calculated using the < operator for String. This means that if the strings are of different lengths, and the strings are equal when compared up to the shortest length, then the longer string is considered of higher lexical precedence than the shorter one. For example, one would expect the tables "paper_boxes" and "papers" to generate a join table name of "papers_paper_boxes" because of the length of the name "paper_boxes", but it in fact generates a join table name of "paper_boxes_papers". Be aware of this caveat, and use the custom :join_table option if you need to.

The join table should not have a primary key or a model associated with it. You must manually generate the join table with a migration such as this:

class CreateDevelopersProjectsJoinTable < ActiveRecord::Migration
def self.up
create_table :developers_projects, :id => false do |t|
t.integer :developer_id
t.integer :project_id
end
end

def self.down
drop_table :developers_projects
end
end

Custom Join Table Example

For Products and Categories default join table in lexical order is
categories_products.

if we want to use custom join table (prod_cats) than use 'join_table' option

class Products < ActiveRecord::Base
has_and_belongs_to_many :categories, :join_table => :prod_cats
end

class Categories < ActiveRecord::Base
has_and_belongs_to_many :products, :join_table => :prod_cats
end