In a keynote at the Silicon Valley Ruby Conference last week, Bray called Rails “a big deal, a hot deal”. And the Sun Microsystems director of web technologies is walking it likes he talks it: he’s using a lot of Ruby for his development.

But…

“Let’s face the facts: Ruby is too slow,” Bray told delegates. He says Ruby 1.8.6 – which dominates the enterprise landscape – is up to 20 times slower than Java.

And, despite tests, the cause of the problem remains unclear – is it compilation of Ruby or “some pretty freaking complex and scary stuff” in Rails.

“When you start to run Rails, you get wildly non-linear performance. Rails has worked well on Ruby 1.8.6… everything else is a work in progress. It’s weird and it’s hard to understand,” Bray said.

“Ruby is richly festooned with core libraries and APIs that aren’t built in Ruby, they are built in C,” he said.

Fellow keynote speaker John Lam, a Microsoft project manager who’s leading work porting Ruby to the .NET Framework with IronRuby, also noted “strange anomalies” in the way Ruby works.

Various initiatives are underway to address the Ruby speed problem. These include the Smalltalk-inspired Rubinus that Sun is supporting; the somewhat obscure Maglev; and – of course – JRuby. This runs on the Java Virtual Machine and is up to five times faster than Ruby, according to Bray.

In spite of the go slow, Bray delivered a robust endorsement of Ruby on Rails. For him, the Rails framework drives Ruby’s success and gives Ruby an edge over PHP and Sun’s beloved Java in speed of development, scalability and maintainability. “The majority of Ruby in the world is driven by Rails,” he said.

Rails offers a clean, prescribed and predictable framework that – like PHP – get some of their advantage from choosing to do less. Java Enterprise Edition, meanwhile, is designed for “infinite flexibility”.

PHP is widespread and is used in massive applications such as Facebook and Wikipedia, but the accompanying PHP frameworks such as CakePHP, have not followed in terms of deployment, breeding “spaghetti code” that’s difficult to fix and extend.

According to Bray, the prescriptive nature of the Rails framework suits most web front-ended applications’ database batch needs when it comes to create, repeat, update and delete. The downside? If you need your database calls to do something a little different, you’re on your own.

Rails also encourages best practices, through the use of test-driven development to improve construction and model view controller to help maintain applications.

Speed of development is the number-one reason that CTOs at big banks and airlines are calling Bray in to advise on Ruby. “They’ve heard it gives them applications in months rather than years. That’s why Ruby came out of nowhere,” he said. “You can get something done faster in Ruby once you’ve got it built, you can do updates and maintenance faster than you can in PHP.”

Other languages could learn a thing or two from Rails and Bray predicts frameworks would become more “Rails-like” – meaning the future does not belong to Ruby on Rails alone.

In this piece, I shall show how well Ruby on Rails has been integrated into NetBeans using the creation of a very simple application as an example.

I’m going to build a simple link sharing application – which we’ll call Linkshare – along the lines of Reddit . The functionality is straightforward: users can post interesting links to the site. Links can be displayed, updated and deleted: in others words, perform the most basic of database procedures on these posts.

For our backend database we’ll use MySQL. So, before we kick off any of the Rails stuff, log on to your database server and create a database called Linkshare. And, for convenience create a user called ls. We’ll leave the password blank for this tutorial.

We can use NetBeans to connect to this empty database to check that we can connect to the server and to see what state the database is in. Click on the Services tab in NetBeans, expand the Databases tree, right click on Drivers and select the MySQL node, then right click and select Connect Using on the New Connection dialog, enter the database URL and the user name, and hit OK. NetBeans will make the connection, and once it’s done you can expand the tree still further to view Tables, Views and Procedures (which should be empty).

The next step is to create the Linkshare project. File New starts the new project wizard and clicking on the Ruby category gives us a number of choices, including Ruby on Rails application. Clicking Next allows us to give the project a name – Linkshare – and to pick which RDBMS we want to use. When we click on the Finish button, Rails will do its stuff and generate the entire application structure for us.

Once that’s in place, we need to tell the project how to connect to the database. From the Projects tab expand the Linkshare project, navigate to the Configuration node and then double click on the database.yml file to open it in the editor. Change the development database section so that it matches your connection settings:

development:   adapter: mysql   database: linkshare   username: ls   password:   host: <your host name or IP address>

Now, a major part of the Ruby on Rails architecture is an implementation of the Model-View-Controller (MVC) and ActiveRecord design patterns. If you’re unfamiliar with the terminology don’t worry, Ruby on Rails makes things simple for you. The model is a fancy way of talking about the database. And we’ll add to ours by creating a table called links to store all of the links that users are going to post to our site.

Right click on the Linkshare node in Projects, select Generate and from the drop-down menu pick Model. For each link our users enter we want the URL and some description, so for the Arguments field we specify:

Link url:string description:text

When we hit OK, Rails does more application generation, including the creation of a script to set up and tear down the database table for us. The file that’s generated is called 001_create_links.rb, and looks like this:

class CreateLinks < ActiveRecord::Migration   def self.up     create_table :links do |t|       t.column :url, :string       t.column :description, :text     end   end    def self.down     drop_table :links   end end

To run this, right click on the Linkshare node again, select Migrate Database > Current Version to connect to the database and create the links table. Once that’s done, switch to the Services tab, select the Database connection and hit Refresh, click on the Tables node to see that there is indeed a links table, with fields for URL and description (as well as an ID field that was automatically added for us).

class PostController < ApplicationController   scaffold :link end

The final thing is to make sure that requests are routed to the correct place, so edit the routes.rb file (which is under the Configuration > Environments node of the Linkshare project tree). Adding the following line should route requests to the post controller:

map.connect ' ', :controller => "link"

With that in place, press F6 (or click on the big green Run Main Project button on the main tool bar) and launch the WEBrick web server with our Ruby on Rails application in place. Opening a browser and entering the URL http://localhost:3000/post will take us to a very basic looking web page that enables us to add, edit, list and delete posts.

Want to do more? Say, we decide to add a tags field so we have an idea what each URL is about. Easy. In the NetBeans Generator, menu select Migration, enter “new_tags_field” and then hit OK. This creates a new class called 002_new_tags_field.rb and opens the file in the editor. We’ll make use of one of NetBeans keyboard triggers to make life simple for us. Enter a new line under def self.up, then enter mcol and then press the tab key. This expands to:

add_column :table, :column, :string

Change this to:

add_column :links, :tags, :string

Save the change, run the Migrate Database command to add a new tags field to the links table. Hit Refresh in the browser, click on the New Link button and, hey presto, there’s a tags field as well.

It might not look like much, but we have the skeleton of a useful web application, created in just a few minutes. Enhancing the application with validations, adding new fields or functions (like voting buttons), or adding some better formatting can all be done with a few key strokes or mouse clicks.

It’s why Ruby on Rails has made such a splash, and shows how well Ruby on Rails has been integrated into NetBeans.

Rather than repeat the work on Microsoft’s own IronRuby, Ruby.NET is closing its doors just three months after its latest milestone release, and following an initial wave of developer buzz,.

Microsoft, meanwhile, has welcomed Ruby.NET project participants to its IronRuby project, licensed under the Microsoft Public License (Ms-PL).

John Lam, a Microsoft Dynamic Language Runtime (DLR) team programmer, said Ruby.NET project leader Wayne Kelly is “refocusing” his efforts on IronRuby.

Kelly has moved to head off suggestions Microsoft pressured him to kill Ruby.NET, which initially received funding from Microsoft Research. Ruby.NET lags IronRuby overall, but its parser is being added to Microsoft’s effort.

Kelly indicated on the Ruby.NET mailing list that Ruby.NET was simply overtaken despite getting a good head start.

Last year’s release of Microsoft’s IronRuby had called into question Ruby.NET’s “unstated goal” of heading towards a production-quality version. Kelly got on board with IronRuby following last week’s Lang.NET Symposium where the projects compared progress. “I’ve come to the conclusion that the DLR is clearly here to stay – it’s becoming an even more important part of the Microsoft platform,” Kelly said.

“Whilst Ruby.NET initially had a good head start on the IronRuby project; by incorporating the Ruby.NET parser and scanner and by leveraging the DLR, I now believe that IronRuby is more likely to succeed as a production-quality implementation of Ruby on the .NET platform,” Kelly said.

The DLR, unveiled by Microsoft in May 2007, adds a set of features to the .NET framework’s Common Language Runtime (CLR) designed to improve the performance of scripting languages on the CLR and to also enable them to share code.

Lam, who joined Microsoft in 2006 having built the RubyCLR for Ruby applications on .NET, welcomed the end of duplicate Ruby efforts. “More people working in parallel on libraries means that folks will get a working Ruby on .NET that runs real programs sooner. And that’s goodness for everyone, from the contributors who want to see their code used, to devs who want to write Ruby programs on the .NET,” he said.

On the one hand Sun’s director of web technologies Tim Bray predicts a healthy future for Ruby and Rails – while also acknowledging that they could face some stiff competition from alternatives. On the other hand Joe Gregario at BitWorking maintains that Ruby and Rails peaked in mid 2007 and, citing various Web 2.0 trend statistics, reckons its downhill from now on.

The flak attack on the Ruby and Rails communities notched up a level with a vitriolic rant last week from Mongrel creator Zed Shaw who declared Rails a “ghetto” populated by – well, according to Zed at least, some not very nice people. The community responded at length.

The Ruby cause has not been helped by high-profile failures such as Derek Civers of CD Baby revealing last September that he had abandoned a re-write of his site with Ruby on Rails and gone back to PHP scripting. And earlier in the year Twitter blamed Ruby on Rails for degraded performance on its site.

The main grouses appear to be about performance and the scalability of applications built with Ruby and Rails.

There is some evidence that performance has improved with Rails 2.0 released just before Christmas and scalability is clearly no problem if you have God (and Zed Shaw) on your side.

The availability of full versions of Ruby for Microsoft’s .NET in the form of IronRuby from Microsoft and Ruby.NET, launched in November 2007, should also help increase uptake of Ruby.

But as Tim Bray notes in his positive forecast for Ruby and Rails, there will be pressure on both during the coming year. Alternatives to Rails such as Ramaze clearly appeal to developers and there is still strong support for established languages such as PHP and Java

Bray, who is Director of Web Technologies at Sun Microsystems, co-creator of the XML 1.0 and XML Namespace standards, co-founder of Open-Text, and contributor to the Atom Publishing standard (whew!) spoke in a presentation entitled “How to combine PHP technology with Java based on Enterprise Systems”

In the slide below, Bray outlines the basic advantages of each of these three platforms (or rather the two languages and one framework if you are scoring at home). In perhaps in a nod to his new employer, Sun, Bray totally omits any mention of .NET or smaller products like Adobe’s Flex/ColdFusion platform.

His idea, if you are able to take it on the surface only, is to rate your priorities of: 1) Scalability, 2) Dev Speed, 3) Dev Tools, and 4) Maintainability. In this highly generalized approach, you could theoretically pick your web application building language/framework based on only these priorities.

Tim weighs-in heavy on the maintainability side, and we’d tend to agree with him. To quote:
“Good apps, once built, tend to be in production for an astonishingly long time. Which means that they have to be maintained for an astonishingly long time. Which means that maintainability is important. There are a lot of things that go into maintainability, but I suggest that the biggies are object-orientation, MVC architecture, code readability, and code size.”

On the maintainability side Tim places Ruby on Rails out front. Quoting him again, Tim describes why RoR is in the lead here.

“Mostly because there’s less code. The fact that Ruby forces MVC on you helps too, also the fact that the templating and [Object Relational Mapping (ORM)] and testing and application code are all so tightly integrated helps. Bear in mind that we still don’t know how well Rails is going to work outside of the CRUD-centered greenfield app space where it shines.”

Tim’s metrics don’t really exist on a quantitative level nor are they based on any published statistics — just a very informed intellect and a privileged position. Obviously, additional parameters such as total cost of ownership and native security (PHP, we are looking at you) should also play a big role the decision making process.

As you can probably guess, in response to this presentation, the proponents of Java, PHP and Ruby are lighting the Internet aflame in defense of their platform of choice and at the same time nay-saying their fellow players. While very entertaining and sometimes educational to follow, not much is going to be gained from this bickering.

Bray concludes the presentation with the Rodney King-esque statement “One way or another we all have to integrate.”

The reality is that there are a great number of ways to hone-in on the language or framework choice for a web application. Many factors have to be considered and weighed against each other. The beauty of what we have today is that there ARE a great many choices out there, much more-so than even a few years ago.

The first thing to understand about Rails is its model/view/controller (MVC) architecture. While this approach is not unique to Rails — or even to Web applications as opposed to other programs — Rails provides a very clear and focused MVC way of thinking. If you stray from the MVC approach, Rails becomes far less useful than if you follow its paradigm.

The model

The model part of a Rails application is primarily the underlying database it uses. In fact, in many ways a Rails application is just a way to perform manipulations on the data in a relational database management system (RDBMS) in a directed way.

A central component of Rails is the class ActiveRecord, which maps relational tables to Ruby objects and thereby to the data manipulated by controllers and shown in views. Rails applications are particularly likely to use the ubiquitous MySQL database, but bindings exist for a number of other RDBMSs, including IBM® DB2®.

If you like, you can add Ruby code to perform extra validation within an application model, enforce data relationships, or trigger other actions. The Ruby files within an application’s app/models/ directory can call a variety of validation methods of ActiveRecord. However, you can also leave the model code as a stub as well and rely only on the constraints of the RDBMS that holds the data. For example, the application I develop in this example contains only this skeleton model code (at least initially):

Listing 1. Skeleton model app/models/contact.rb

class Contact < ActiveRecord::Base
end

The controllers

Controllers carry out your application logic in its abstract form. That is, the Ruby scripts in an application’s app/controllers/ directory will load model data into variables, save it back, and massage and manipulate it. But controllers are not concerned with how the data is concretely presented and entered by users. In the general MVC paradigm, this can allow the user multiple styles of interaction with the same controller: a native GUI, a Web interface, and a speech interface for the visually impaired might all interact with the same controller.

Rails is not quite so general as that, though; instead, it is more narrowly focused on providing and collecting data within Web pages. Nonetheless, you can modify the layout of those Web pages — colors, fonts, tables, stylesheets, etc. — independently of controller code.

The views

Rails views are where we leave Ruby code. Rails contains a very nice template language for .rhtml files that combines pure HTML with embedded Ruby code. The very surface appearance of a Rails application screen is generally controlled by CSS stylesheets. The .rhtml format is an enhancement of HTML. Actually, a simple HTML file by itself is also a valid RHTML template, but there is not much point in omitting the scripting control that RHTML gives you.

RHTML is a true template format — not simply a way of embedding code in HTML — and this is a much more powerful approach. If you’re familiar with PHP, think of the contrast between PHP itself and Smarty templates. That is, embedded scripting just intermixes code with uninterpreted HTML; the code portion is still responsible for issuing print statements when it wants to say something to the client.

In contrast, a template engine adds a custom set of tags to HTML that allows you to express conditions, loops, and other logic as part of the enhanced HTML markup.

Generating code

The tools that Rails provides are basically a set of code generators. I like this approach much better than that of a development environment that forces me to use a rigid workspace and IDE. Rails does not get in your way, but nonetheless saves most of the work of manual programming — or at least eases you into the parts that require manual coding by providing first-pass scaffolding “for free.”

The concept of scaffolding is a central notion in Rails. Very simple applications can almost entirely avoid custom coding by letting Rails dynamically generate client HTML pages as it runs. A first pass at code generation creates just the raw scaffolding; you can subsequently generate more specific controllers, views, and models that you can customize. But you need not generate much to get started.

Rails relies on a fixed and fairly common-sense organization of its files, but this organization is relatively rigid. You will just be picking a fight with the Rails environment if you try to force other file and code organizations. Then again, I cannot see a reason not to go along with the organization Rails provides; for the most part, it “fits your brain” (as Ruby fans like to say). For example, the directory names and their organization are probably pretty darn close to what you would choose if you were designing a framework from scratch (at least if you think in the “Ruby way”).

Building a simple application

Several tutorials are available on the Ruby on Rails Web site that can walk you through creating a simple Rails application (see Resources). The sample application here is like them, since there is a certain way to get started right in building a Rails application. Given the relatively short length of this introduction, I do recommend one of those longer tutorials so you can get a more thorough grounding.

The sample application is a basic address book. It demonstrates the general steps for creating an application:

1. Generate the model (in which you create a MySQL database and table).
2. Generate the application (includes generating basic code and directories).
3. Get Rails running (and configure database access).
4. Create some content (includes generating the scaffold model and controller and telling the controller to use the scaffold).

We’ll look at each step in detail.

Generating the AddressBook model

The first thing you need to do for any application is create a database for its data to live in. Technically, this step need not occur first, but it needs to occur early; it should be obvious that you should create the database before any application code, even automatically generated code. So let’s create a database in MySQL and craft a first table within this database. (Consult other documentation for how to get MySQL or another RDBMS up and running.)

Let’s assume MySQL is installed and available.

Listing 2. Creating a MySQL database and table
[~/Sites]$ cat AddressBook.sql
CREATE DATABASE IF NOT EXISTS AddressBook;
USE AddressBook;
CREATE TABLE IF NOT EXISTS contacts (
id smallint(5) unsigned NOT NULL auto_increment,
name varchar(30) NOT NULL default ”,
created_on timestamp(14) NOT NULL,
updated_on timestamp(14) NOT NULL,
PRIMARY KEY (id),
UNIQUE KEY name_key (name)
) TYPE=MyISAM COMMENT=’List of Contacts’;
[~/Sites]$ cat AddressBook.sql | mysql
There are a couple things to notice in this first table. Of central importance is that every table must have an id column with exactly that name. Rails uses the primary key column id for various recordkeeping and referencing tasks. The fields created_on and updated_on are not required, but if you do include them, Rails maintains them automatically “behind the scenes”; in most cases there is no harm in using these timestamps. So the only “real” data you have yet added is a name for your address book contacts.

Another little oddity exists with the Rails’ use of singular and plural names for various things. Various items are renamed between singular and plural versions depending on their usage and context. Table names should use the plural form. I have not experimented with words having irregular plurals; words like datum and data might trip up Rails.

Generating the AddressBook application

Now that you have a database to interact with, create the AddressBook application. The first step is simply running rails to generate the basic directories and scaffold code:

Listing 3. Generating basic code and directories

[~/Sites]$ rails AddressBook
create
create app/apis
create app/controllers
create app/helpers
create app/models
create app/views/layouts
create config/environments
create components
[...]
create public/images
create public/javascripts
create public/stylesheets
create script
[...]
create README
create script/generate
create script/server
[...]

I have abridged the output from running rails; the omitted lines just remind you of various files and directories that were created. Try it on your system and browse through all the created files. I’ve displayed a few of the most important files and directories in the code.

Running Rails

Having created the AddressBook/ directory and needed children, you need to perform just a bare initial configuration. First, set the database by modifying a YAML configuration file like so:

Listing 4. Configure database access

[~/Sites]$ cd AddressBook
[~/Sites/AddressBook]$ head -6 config/database.yml # after editing
development:
adapter: mysql
database: AddressBook
host: localhost
username: some_user
password: password_if_needed

Finally, you need to serve the data. Rails comes with its own single-function Web server, WEBrick, which is perfectly good for our experiment. You might also follow instructions at the Ruby on Rails Web site to configure Apache or other servers to serve Rails applications via FCGI (or plain CGI, but plain CGI will be slow).

Listing 5. Kicking over the WEBrick server

[~/Sites/AddressBook]$ ruby script/server -d
=> Rails application started on http://0.0.0.0:3000
[2005-03-21 17:57:38] INFO WEBrick 1.3.1
[2005-03-21 17:57:38] INFO ruby 1.8.2 (2004-12-25) [powerpc-darwin7.8.0]

Creating a little content

The prior steps are enough to let you view a welcome splash page on the WEBrick port. For example, on my local system, I can now view http://gnosis-powerbook.local:3000/. But you need to generate just a bit more code to manipulate your custom database. You can do this with the script generate, which was created within your AddressBook/ application directory:

Listing 6. Code generation of scaffold model and controller

[~/Sites/AddressBook]$ ruby script/generate model contact
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/contact.rb
create test/unit/contact_test.rb
create test/fixtures/contacts.yml
[~/Sites/AddressBook]$ ruby script/generate controller contact
exists app/controllers/
exists app/helpers/
create app/views/contact
exists test/functional/
create app/controllers/contact_controller.rb
create test/functional/contact_controller_test.rb
create app/helpers/contact_helper.rb

Notice here that you should use the singular contact rather than the plural contacts in the corresponding table name.

Now you need to edit one more generated file, just a bit, to get the controller to use the scaffold:

Listing 7. Telling the controller to use the scaffold

[~/Sites/AddressBook]$ cat app/controllers/contact_controller.rb
class ContactController < ApplicationController
model :contact
scaffold :contact
end

Now you can view and modify the contents of your database at a URL like http://rails.server/contact/ (in my test case, it’s http://gnosis-powerbook.local:3000/contact/). After entering a little data, it looks something like Figure 1 and Figure 2:

Figure 1. Listing contacts
Listing contacts

Figure 2. Editing contact
Editing contact

Creating customizable content

The previous code creates a fully working interface to view and modify your database, but all the formatting, presentation, and business logic (such as there is) are done dynamically by Rails without any great sophistication. In order to create something a bit more custom, you need to generate a bit more code. What we need now is for Rails to explicitly write out all the scaffolding it is implicitly generating on the fly so that we can tinker with it.

Listing 8. Code generation of explicit controller and view

[~/Sites/AddressBook]$ ruby script/generate scaffold Contact
dependency model
[...]
create app/views/contacts
exists test/functional/
create app/controllers/contacts_controller.rb
create test/functional/contacts_controller_test.rb
create app/helpers/contacts_helper.rb
create app/views/layouts/contacts.rhtml
create public/stylesheets/scaffold.css
create app/views/contacts/list.rhtml
create app/views/contacts/show.rhtml
create app/views/contacts/new.rhtml
create app/views/contacts/edit.rhtml

Now there’s a bit more to work with, so try modifying a few things. (Notice that this code has gone back to the plural form contacts, for reasons not clear to me; we need to accept it for now.) Try changing a few colors and fonts in the CSS:

Listing 9. Configuring the cascading stylesheets

[~/Sites/AddressBook]$ head -8 public/stylesheets/scaffold.css
body { background-color: #ffe; color: #338; }
body, p, ol, ul, td {
font-family: verdana, arial, helvetica, sans-serif;
font-size: 13px;
}
td { border: 1px solid; }
a { color: #eef; background-color: #446; }
a:hover { color: #fff; background-color:#000; }

Now that you have the code, what does contacts_controller.rb do? It is more explicit and configurable in its action than the contact_controller.rb you saw in the previous code. In part, the controller looks like this:

Listing 10. Controller app/controllers/contacts_controller.rb

class ContactsController < ApplicationController
def list
@contacts = Contact.find_all
end
def show
@contact = Contact.find(@params['id'])
end
def create
@contact = Contact.new(@params['contact'])
if @contact.save
flash['notice'] = ‘Contact was successfully created.’
redirect_to :action => ‘list’
else
render_action ‘new’
end
end

As promised, a controller’s main job is to load data into variables. The object Contact is the ActiveRecord object-relational mapping that the model provides. The variables @contacts or @contact are given data in their appropriate methods. The methods are themselves referred to by URLs such as http://rails.server/contacts/show/2 (this one shows the contact with id of “2″).

The controller in this example ultimately connects to views, RHTML files that make use of the data values loaded into variables by the controller. For example, here’s part of the list view:

Listing 11. List view app/views/contacts/list.rhtml

[...]
<% for contact in @contacts %>
<tr>
<% for column in Contact.content_columns %>
<td><%=h contact.send(column.name) %></td>
<% end %>
<td><%= link_to ‘Show’, :action => ‘show’, :id => contact.id %></td>
<td><%= link_to ‘Edit’, :action => ‘edit’, :id => contact.id %></td>
<td><%= link_to ‘Destroy’, :action => ‘destroy’, :id => contact.id %></td>
</tr>
<% end %>
[...]

The method ContactsController.list loads the variable @contacts, and the flow control tags in RHTML pull out the individual records from the array.

Changing the model

The initial model contained only a name for a contact. Unfortunately, I don’t have room in this article to expand the model to include actual contact data like phone numbers, addresses, emails, etc. In general, that data would live in a child table with a foreign key relation to the table contacts. The Rails model would indicate the relation with custom code something like this:

Listing 12. Custom code app\models\phone.rb

class Phone < ActiveRecord::Base
belongs_to :contact
end

Before wrapping up, let’s change the data model just slightly and see how that affects the application. First, add a column:

Listing 13. Adding first_met date to model

$ cat add-contact-date.sql
USE AddressBook;
ALTER TABLE contacts ADD first_met date;
$ cat add-contact-date.sql | mysql

Now that you’ve changed the underlying model, http://rails.server/contact/ — the behind-the-scenes version of the scaffolding — simply adjusts with no effort on your part. The controller and view are fully automated based on the model. But the application version at http://rails.server/contacts/ with our hand-tweaked files is not quite as automatic.

The list view automatically looks for all the columns, whatever they might be, by including Contact.content_columns as part of the template loop. But other views such as edit have already been generated, and you need to add your new data fields. For example:

Listing 14. Edit view app/views/contacts/edit.rhtml

<h1>Editing contact</h1>
<%= error_messages_for ‘contact’ %>
<%= start_form_tag :action => ‘update’ %>
<%= hidden_field ‘contact’, ‘id’ %>
<p><label for=”contact_name”>Name</label><br/>
<%= text_field ‘contact’, ‘name’ %></p>
<p><label for=”first_met”>Known Since</label><br/>
<%= date_select “contact”, “first_met”, :use_month_numbers => false %></p>
<input type=”submit” value=”Update” />
<%= end_form_tag %>
<%= link_to ‘Show’, :action => ‘show’, :id => @contact.id %> |
<%= link_to ‘Back’, :action => ‘list’ %>

Conclusion

Rails gives you an extremely quick way to develop flexible Web applications; this introduction just barely touched on what it’s like to work with Rails. The full framework contains many useful classes and methods for carrying out the actions most used in Web-based applications.

The best thing about Rails is that it fosters a whole “Rails way of thinking,” since it comes complete with all the supporting code you need. This is a big plus over other toolkits and frameworks that just give raw materials to work with. Rails development offers you a clear path from a half-formed idea to a fully functioning Web application.