RAILSBreaking all the myths (only 6 to be precise)

Swaathi Kakarla Co-founder, Skcript

MYTH #1 - @variables are magical

TRUTH: They aren’t.These are normal variables. You can even call it @dogsrule even if

your controller name is PostsController. ALL that an instance variable does is pass data to the view. There

is no other way to do it.

They are also not set by themselves. Computers are not that smart yet.

We have to define them. In something called the “before_filter”.

MYTH #2 - Helpers are unnecessary

TRUTH: Not all the time.

- We use them to reduce logic in our views. - To reuse things done repeatedly in the views. - Eg., check_user(user) - Even link_to is a helper! It’s a Rails helper. - They are global! PostsHelper can access a @user variable.

- EXTREMELY useful for UI. You can even write HTML code here. And that can be made dynamic with the value passed to it.

MYTH #3 - Model or Controller?TRUTH: Go back to OOPs concepts!

@post is an object of the Post class. CLASS -> Model, OBJECT -> instance variable

So now, your @post can access functions written in the model. Because it is accessing it’s methods defined in it’s class. And the

columns are actually the instance variables.

A session only goes to the controller, not the model. So “Should I write code in the model or controller?” does not exist.

Your @post can always access the class (model) methods.

So what should I write in the model?Logic pertaining to an object, (variable) that can be called upon wherever you are, as long as you have an instance of the class

(object).

Ex. Editing the name of a myfolder.

CONTROLLER CODE MODEL CODE

- Remains for a single session. - Controller becomes huge. - Not reusable. (Functions in the

controller can not be called anywhere.)

- Can be reused anywhere, called with an instance of the class.

- Model can be as huge as possible. - Readable, Modular, Beautiful!

MYTH #4 - Code can be written only in the controller, model and helper.

TRUTH: No way!

Write code in, - /config/initializer - /lib - /lib/tasks

Initializer - Loaded only once during server lifetime, loaded first. Put configuration variables that do not change here. Library - Make modular classes/modules that can be called ANYWHERE in a Rails app. Even in the model. Just use require/include! Tasks - Rake tasks are useful for server admins. Something external changed in your code? Like reindexing a search field? Put it in a rake task and have everyone execute it, WITHOUT touching the rails console.

MYTH #5 - Routes - complicated AF!TRUTH: You can do them in your sleep.

HTTP Method ‘path-in-url-box’ => ‘controller#action’, as: :helper_name

get ‘/subs’ => ‘users#sub’, as: sub

link_to “Your Timeline”, sub_path

Want to pass data to the contoller? Use params!get ‘/subs/:id’ => ‘users#sub’, as: sub

link_to “#{user.name}’s Timeline”, sub_path(user)

So what ID is passed? That’s defined by the to_param function in Rails.

Mostly the ID is the id of the record. FriendlyID over rides the to_param block and passes name.

BEST Part: You don’t have to do anything! Just pass the entire object, the to_param function will take the one it needs. This way, even if in the future

the to_param block changes, it does not break the entire code.

Want to pass specific data to the controller?get ‘/subs/:entity’ => ‘users#sub’, as: sub

link_to “Product’s Timeline”, sub_path(:entity => :product)link_to “Post’s Timeline”, sub_path(:entity => :post)

def sub @entity = params[:entity]

end

Routes with multiple data passed?

get ‘/subs/:id/:entity’ => ‘users#sub’, as: sublink_to “{user.name} ’s Product Timeline”, sub_path(user, :entity

=> :product)

Maintain the order in which you have defined the routes!

And many many more types are there! Just look at out routes file. Before you ponder, run rake routes.

MYTH #6 - Partials are broken HTMLTRUTH: They are much more.

1. Modularize your HTML<%= render “path-to—partial” %>

2. Pass data between partials - Use Locals!<%= render :partial => “path-to—partial”, :locals => { :name => @variable } %>

3. Render from Javascript

$(‘#id’).html(‘<%= j render :partial => “path-to—partial”, :locals => { :name => @variable } %>’);

4. Use Rails conventions

<%= render @posts %> or <%= render @post %>Create a partial with the same name as the

model inside your views folder. (_post.html.erb)

FLIPSIDE: Can not pass any other data.

Ruby/Rails FTW!def truth

end

!