Ruby on Rails

In general, programming languages fall into one of two

categories: they're either compiled languages or scripting

languages. Let's explore what each of those terms means, and

understand the differences between them.

Compiled Languages: The language in which you write an

application is not actually something that your computer

understands. Your code needs to be translated into bits and

bytes that can be executed by your computer. This process of

translation is called compilation, and any language that

requires compilation is referred to as a compiled language.

Examples of compiled languages include C, C#, and Java.

For a compiled language, the actual compilation is the final

step in the development process. You invoke a compiler --

the software program that translates your final

hand-written, human-readable code into machine-readable code

-- and the compiler creates an executable file. This final

product is then able to execute independently of the

original source code.

Thus, if you make changes to your code, and you want those

changes to be incorporated into the application, you must

stop the running application, recompile it, then start the

application again.

Scripting Languages: On the other hand, a scripting language

such as Ruby, PHP, or Python, relies upon an application's

source code all of the time. Scripting languages don't have

a compiler or a compilation phase per se; instead, they use

an interpreter -- a program that runs on the web server --

to translate hand-written code into machine-executable code

on the fly. The link between the running application and

your hand-crafted code is never severed, because that

scripting code is translated every time it is invoked -- in

other words, for every web page that your application renders.

As you might have gathered from the name, the use of an

interpreter rather than a compiler is the major difference

between a scripting language and a compiled language.

The Great Performance Debate: If you've come from a

compiled-language background, you might be concerned by all

this talk of translating code on the fly -- how does it

affect the application's performance?

These concerns are valid -- translating code on the web

server every time it's needed is certainly more expensive,

performance-wise, than executing pre-compiled code, as it

requires more effort on the part of your machine's

processor. The good news is that there are ways to speed up

scripted languages, including techniques such as code

caching and persistent interpreters. However, both topics

are beyond the scope of this book.

There's also an upside to scripted languages in terms of

performance -- namely, your performance while developing an

application.

Imagine that you've just compiled a shiny new Java

application, and launched it for the first time ... and then

you notice a typo on the welcome screen. To fix it, you have

to stop your application, go back to the source code, fix

the typo, wait for the code to recompile, and restart your

application to confirm that it is fixed. And if you find

another typo, you'll need to repeat that process again.

Lather, rinse, repeat.

In a scripting language, you can fix the typo and just

reload the page in your browser -- no restart, no recompile,

no nothing. It's as simple as that.

form_for and form_tag both are used to submit the form in

ruby on rails.

but the way of handling objects related to model is

different.

form_for:

you should use form_for for a specific model i.e while

crating an new row in database. form_for will perform the

standard http post which is having fields related to active

record objects.

here is the example for using form_for in ruby on rails:

<% form_for :user, @user, :url => { :action => "update" }

do |f| %>

then in here you can use the f object to create input

field.

First name: <%= f.text_field :firstname %>

Last name : <%= f.text_field :lastname %>

Biography : <%= f.text_area :biography %>

<% end %>

form_tag:

form_tag just creates an form as an normal form. form_for

will perform the standard http post without any model

backed and has normal fields. this is used mainly when

specific things need to be submitted via form

here is the example for using form_tag in ruby on rails:

<% form_tag '/posts' do -%>

<%= text_field_tag "post", "firstname" %>

<% end -%>

(1) Introduction of bundler (New way to manage your gem

dependencies)

* (2) Gemfile and Gemfile.lock (Where all your gem

dependencies lies, instead of environment.rb)

* (3) A new .rb file in config/ folder, named as

application.rb (Which has everything that previously

environment.rb had)

* (4) Change in SQL Structure: Model.where(:activated => true)

* (5) All the mailer script will now be in app/mailers

folder, earlier we kept inside app/models.

* (6) Rails3-UJS support. for links and forms to work as

AJAX, instead of writing complex lines of code, we write

:remote => true

* (7) HTML 5 support.

* (8) Changes in the model based validation syntax:

validates :name, :presence => true

* (9) Ability to install

windows/ruby/jruby/development/production specific gems to

Gemfile.

group :production do

gem 'will_paginate'

end

Conventional web application transmit information to and

from the sever using synchronous requests. This means you

fill out a form, hit submit, and get directed to a new page

with new information from the server.

When you interact with an Ajax-powered web page, it loads an

Ajax engine in the background. In response to an event web

application passes asynchronous request (XMLHttpRequest or

xhr). In fact it is javaScript object/method that performs

asynchronous interaction with the server, JavaScript object

that performs asynchronous interaction with the server and

behind the scene fetches data. and behind the scene fetches

data.

We do request.xhr? only to check the request type, either

its AJAX request or others(post, get).

With Rails 2.0, you may have noticed that dynamic

scaffolding breaks–that is, if you have a controller with

scaffold :model_name in it, all the scaffolded actions–new,

delete, index–no longer exist! In Rails 2.0, you can only

generate static scaffolding–that is, you can use the

scaffold to generate the files for controllers, models, and

views.

What’s more, Rails 2.0 allows you to specify the model

attributes inside the scaffold. This then creates views with

all the appropriate fields, and it also creates the

migration with all the fields in it! Excellent!

As an example, say we wanted to create a blog-post model. We

could generate it like so:

script/generate scaffold Post title:string content:text

category_id:integer

You’ll notice Rails will generate, among other things:

► A post.rb model file

► A posts_controller.rb controller file

► A posts view folder containing views for the index, show, new, and edit actions

► A DB migration called xxx_create_posts

► A unit-test, fixtures file, and helper

Everything you need–indeed, everything the dynamic

scaffolding provided–is included, albeit as static content.

All you need to do is migrate your DB and you’re up and flying!

So the main difference is, with dynamic scaffolding you can

generate new, edit and delete methods but with static

scaffolding you can't