Media72 Hosting Articles and Tips

Anyone that has used Rails 1.2.3, 1.2.4 or 1.2.5 may have noticed a number of deprecation notices in their development logs. Whilst these deprecated methods still work as expected in 1.2.x versions, you will come-a-cropper when you try to upgrade to Rails 2.0. So what do you need to do and what tools are out there to help you with the move? Glad you asked.

The first thing you can do it run your code through a code checker — Geoffrey Grosenbach has released a great rake task which digs through your code looking for the old methods. It will give you hints of how to fix the issues, but lets look at them a little more closely.

@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 %>
       <!-- Form stuff -->
   <%= end_form_tag %>

becomes

    <% form_tag do %>
        <!-- Form stuff -->
    <% 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 %>
        <!-- Form stuff -->
    <% 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.

So hop to it and get your web apps upgraded now before the rush!

This article provided by sitepoint.com.

So Apples new operating system comes with Ruby and Rails pre-installed along with a few standard gems. It does however lack a few things you may need to get your computer running as a development machine.
(more…)

The seed has been sewn for the next major release of the Ruby on Rails framework. Towards the end of last month, the Preview Release was announced and now that I have had a chance to play with it, I thought it timely to outline some of the new features.

Multiple Views

In version 1.2 of Rails, the respond_to block was introduced, which made serving up differerent data types, like XML or JSON really easy. All you needed to do was something like this:

def index
    @stories = Story.find :all
    respond to { |format|
        format.html {}
        format.xml {
            render :xml => @stories.to_xml
        }
        format.json {
            render :json => @stories.to_json
        }
    }
end

Then, on the web browser, if you appended the file extension (eg /stories/index.xml) and you would get the content delivered in the requested format. You could even create your own custom types by adding MIME::Type.register to the bottom of your environment.rb file.

One of the problems with this approach though, was there was no way to serve up different HTML pages based on the file extension. Because of the way the MIME::Type parser worked, adding another content handler with a mime type of text/html clobbered the default handler which meant the above code would serve up the wrong view.

Enter Mime::Type.register_alias

Now you can tell Rails to respond with HTML to as many file types as you like! Say you are designing a mobile version and an iPhone version of your site, you can create two new formats by dropping the following code in to the new /config/initializers/mime_types.rb file:

Mime::Type.register_alias "text/html", :iphone
Mime::Type.register_alias "text/html", :mobile

This makes the following possible:

def index
    @stories = Story.find :all
    respond to { |format|
        format.html {}
        format.xml {
            render :xml => @stories.to_xml
        }
        format.json {
            render :json => @stories.to_json
        }
        format.iphone {
           // Serve up the iPhone version
        }
        format.mobile {
           // Serve up the mobile version
        }
    }
end

Of course, having to manually render a different version in every respond_to block isn’t very DRY, so a new naming convention has been created for all of the view files. Rather than calling the view file in the example above index.rhtml, you can create three different versions based on the format that you are serving up, eg: index.html.erb, index.iphone.erb and index.mobile.erb.

If rails finds a matching view it will serve that up, if not it will serve up the default .html.erb or .rhtml file. This makes serving up different versions of your site even easier.

This article provided by sitepoint.com.

Hot on the heals of the 1.2.4 release rails 1.2.5 is now out, as usual all of our servers have been upgraded. Rails 1.2.5 is a security and maintenance release that fixes a JSON XSS vulnerability, fixes a couple of minor regressions introduced in 1.2.4, and backports a handful of features and fixes from the 2.0 preview release.
(more…)

Hot on the heals of the Ruby on Rails 2.0 & 1.2.4 announcement the Rails team have released Rails version 1.2.4. At Media72 Hosting we always keep bang up to date with our Rails software so that you guys always have the option of using the latest release. Customers now have the option, on most servers, of using Rails 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.1.6, or 1.1.3, along with our large number of installed gems.

Ever wanted to be able to publish your events calendars online using Apples iCal but don’t want to subscribe to Apples .mac service? With Media72 Hosting you can publish calendars from iCal, and any other application that supports publishing via webdav, just like you can using .mac. Read on for instructions…
(more…)

The preview release of Rails 2.0 has been announced by DHH and says the 2.0 final release is on the way.

“Behold, behold, Rails 2.0 is almost here. But before we can slap on the final stamp, we’re going to pass through a couple of trial release phases. The first is this preview release, which allows you to sample the goodies in their almost finished state.”

(more…)