Get Ready For Rails 2.0

Be Get Prepared for upgrade with Ruby On Rails

Some hints can be followed as below :-

@params, @session, @flash, @env

As of Rails 2.0, you won’t be able to directly access the above instance variables. They have been replaced with methods, which makes customising their actions much easier. It also allows the internals of Rails to change without breaking the API. This is very easy to fix - just remove the @ in front of those variables - they will work exactly the same.


find_all, find_first, render_partial

In earlier version of Rails there were a number of grouped methods, that do very similar things - find, find_all and find_first all fetch records from the database, the only difference is the number of records they return. It was decided to combine these methods in to one where they are differentiated by passed in options. So find_all becomes find(:all) and find_first becomes find(:first) and render_partial becomes render(:partial).

Forms

Out of all the HTML helpers, the form tag was an anomaly because it required a start AND end helper. To make it fit in with way the rest of Rails works and to facilitate dynamic form generation, a block method called form_tag was created. This particular update has a trap in it through - because blocks don’t return values, the ERB tag you use must not have an = sign, so
<%= start_form_tag %>
<%= end_form_tag %>


becomes
<% form_tag do %>
<% end %>



Notice the omission of the equals sign in the latter example?

Also note that passing :post => %gt; true is deprecated. With the push for RESTfulness, the form needs to know about the other HTTP verbs, put and delete, so a new option has been created:
<% form_tag :method => :post do %>
<% end %>

Plugins

A number of what used to be core components of rails have been moved out into plug-ins so as not to clutter the core with stuff that you don’t use very often. It also means that the development of the plugins can be much quicker than that of the core. Probably the major extraction is the third-party database interfaces. Now, by default only MySQL, SQLite and PostgreSQL are supported out of the box. All other databases are supported via gems named activerecord-database-adapter. If you want to use an Oracle just run

gem activerecord-oracle-adapter

and you will be peachy again.

Other extractions of note are the acts_as plug-ins. If you use acts_as_tree or acts_as_list in your model, you will need to script/plugin install them and the built-in pagination has now become the classic_pagination plug-in. Note that by the developers own admission that plug-in is slow (and was slow when it was in core), so if you use it, you may want to think about migrating across to the new and improved will_paginate plug-in.


Hurry up and get upgrade before time get elasped... :)
So GET, SET , Go................................

PHP Vs Ruby

Ajax: Rails and Symfony both use Scriptaculous and Prototype. CakePHP
does, but you have to download and install it separately, which, to
me, calls into question how well they're integrated.

Authentcation: CakePHP has a built-in system, but that system won't
fit all needs, so you'll end up writing custom code anyway.

Caching: CakePHP only has view caching.

Database versioning: None in CakePHP or Symfony, though Symfony has an
XML file for each db table, and, I suppose, you could svn them and
have versioning that way. Migrations in Rails are superior.

Environments: No real separation of environments (prod/dev/test) in
CakePHP.

Console: None in CakePHP. Symfony and Rails, yes. If you want to use
Rails and you think you won't use the console, you're wrong. Once you
understand the power, you'll never want to debug without it.

Testing: Little integrated testing. It produces some stubs when you
"bake" a project, but I prefer how Rails puts those stubs there when
you're creating models and controllers, right from the get-go. (More
on this below.)

Join models: None in CakePHP. Rails has HABTM and has_many :through.
All tables are models in Symfony, so that's almost the same. More
like HABTM with extra info in the table. Propel, Symfony's ORM
engine, is actually quite interesting. (Though, I prefer
ActiveRecord.)

Form validation: Good in all frameworks, but there are some extra
steps involved in dealing with invalid form data in CakePHP.