XML Reference Guide

Now that you've seen how fast you can create an application with Rails, it's time to really start getting down to business. Every Rails application is really a Ruby application, so if you're really serious about building one, you'll need to learn Ruby.

Ruby is not a difficult language to learn as long as you're already familiar with object oriented programming concepts. (If you're not, go ahead and take a detour and familiarize yourself. In the a free trial into Safari and check out The Object-Oriented Thought Process, by Matt Weisfeld.) I'm going to take you through the building of a simple survey application. Many of the steps will seem familiar, with differences only in syntax. But there are few places where you might be surprised at how Ruby handles things.

Let's start with the very basics: input and output.

Input and Output

I'm assuming that by this point you have installed some distribution of Ruby. If you haven't, now is the time. Download a distribution from http://www.ruby-lang.org/en/20020102.html and install it.

Okay, now that that's done, create a new text file and name it survey.rb. In the file, add the following code:

puts "Enter the name for your survey: "
surveyName = gets
puts "The name is: " + surveyName

This is a very simple application, in that all that it does is output a string, wait for you to enter some text (followed by the return key) and output the results. To execute the file, you'll use the ruby executable:

c:\myrubyfiles>ruby survey.rb
Enter the name for your survey:
First Survey
The name is: First Survey

All right, we know that it works, but what did we learn? Well, we learned that there are no particular structures for a Ruby application, for one thing. We didn't have to create a specially formatted file, or delineate the application. We just put commands into it. We didn't even have to end the lines with semicolons. All we had to do was put each command on its own line.

Now, that doesn't mean that a Ruby application is complete chaos. Rather, everything in a Ruby application is an object. For example, our surveyName variable is a String object, so we can access its length attribute:

puts "Enter the name for your survey: "
surveyName = gets
puts "The name is: " + surveyName

print "The name of the survey has "
print surveyName.length
print " characters."

Notice that I've introduced another way to output text: the print statement. You can also use the printf command just as you would in Perl, although I won't cover that here.

You might also see text interpolated into a string using this form:

puts "The name is: #{surveyName}."

If you run the script now, you should see the following:

Enter the name for your survey:
First Survey
The name is: First Survey
The name of the survey has 12 characters.

All right, that's the basics. Now let's look at creating actual classes.

Creating Classes And Using Objects

Before we start creating classes, we should have some idea of what it is we're actually going to create. In this case, we are creating a simple survey application, so we have the following entities:

We have a Survey, which has one or more Questions, each of which has one or more Answers. Each of these entities has specific attributes, such as the answerText and results for the Answer. Let's start by creating the Survey. In your survey.rb file, replace the contents with the following code:

class Survey

   def initialize (givenTitle)
      @title = givenTitle
   end
   
end

nameOfSurvey = "First Survey"
survey = Survey.new(nameOfSurvey)
puts "Survey is called #{survey.title}."

The first section, as you have probably guessed, is the class definition. The initialize method is actually the constructor. In this case, we have created a constructor that takes a single argument representing the title of the survey. We can tell that the title is an attribute of the object (in other words, an instance variable) because of the @ that precedes it.

In fact, allow me to digress for a moment to talk about naming conventions. Notice that the class name is capitalized, and the method is not. Ruby uses these conventions in order to understand how to use a variable. Here is what Ruby expects:

Alright, now that we've got our naming conventions down, let's go back and look at the rest of the code. First were creating a simple string variable, and assigning it a value. Next, we're creating a new variable that is a Survey object by calling its constructor using the new() method. Remember, we only created one constructor, and that is expecting a single parameter. Once we've created the object, we're outputting a string of text and the title attribute.

If you're familiar with objects, this probably seems very straightforward. However, if we run the script like this, we don't get the expected results:

demo.rb:11: undefined method `title' for #<Survey:0x2aa8240 @title="First survey"> (NoMethodError)

What happened here? Well, unless you explicitly create an accessor method, you can't get the value of an attribute. While at first this may seem to go against the "principle of least surprise", consider the fact that it means you don't have to explicitly protect any values from access. You simply provide accessors only for those you wish to access. So how do we do that?

We create a simple method:

class Survey

   def initialize (givenTitle)
      @title = givenTitle
   end
   
   def title
     return @title
   end
   
end

nameOfSurvey = "First Survey"
survey = Survey.new(nameOfSurvey)

survey.title = "Retitled Survey"
puts "Survey is called #{survey.title}"

That solves the accessor problem, but we have the same problem in setting a value, as you can see if you run the script with all of these additions:

demo.rb:16: undefined method `title=' for #<Survey:0x2aa7ee0 @title="First Survey"> (NoMethodError)

So we have to create the setter method too:

class Survey

   def initialize (givenTitle)
      @title = givenTitle
   end
   
   def title
     return @title
   end
   
   def title= (newTitle)
      @title = newTitle
   end
   
end
...

If you're like me, that definition might look a little nutty. But really, you are literally defining what Ruby should do if it encounters the string title=. (In fact, Ruby lets you define a lot of operators this way.)

Now the script will run just fine:

Survey is called Retitled Survey

Fortunately, there is a much easier way to do this. Rather then explicitly creating individual all setter and getter methods, we can tell Ruby to do that for us:

class Survey
   attr_reader :title
   attr_writer :title

   def initialize (givenTitle)
      @title = givenTitle
   end
end
...

The :title notation tells Ruby that we are actually looking for the item called "title" rather than the data pointed to by the title variable. In fact, you can set as many attributes as you like this way using a comma delimited list.

class Survey
   attr_reader :title
   attr_writer :title

   def initialize (givenTitle)
      @title = givenTitle
   end
   
end

class Answer
   attr_reader :answerText, :responses
   attr_writer :responses
   
   def initialize (theAnswer)
      @answerText = theAnswer
      @responses = 0
   end
   
   def answerChosen()
      @responses = @responses + 1
   end
end

nameOfSurvey = "First Survey"
survey = Survey.new(nameOfSurvey)
survey.title = "Retitled Survey"
puts "Survey is called #{survey.title}"