Exploring Ruby on Rails

A discussion about the Rails framework, how to build with it and the benefits of Ruby.
View and Controller Section

LJ: So I understand that you can use this model-class to sling data around in Ruby and have it magically written to the database. How do you go about presenting it to the user and allowing them to interact with it?

DF: It's probably easiest to start with the controller. Basically, Rails decides what object to send a method to based on the URL. So when a request such as


comes in, it ends up calling something like this


LJ: So, the URL is unpacked to decide which method to send and to which controller class to send it to. Aren't there some security issues with that? What if you end up calling some method you didn't intend to expose on your controller object? It seems really unsafe.

DF: That's a good point. It can be unsafe if you're not aware of that, if you add all kinds of functionality as public methods to your controller class, you're exposing all of this functionality to the world. Generally, you put code you don't want to expose to the public in private methods.

LJ: Basically, Rails leverages Ruby's access control and introspection to know what should be exposed to the Web interface. How does it know that? Do you have to configure that?

DF: You can't call just any public method on a controller object, the public methods inherited from the root Object class are filtered and denied. But any public methods that are added to a controller class are automatically available as actions. Instead of configuration you have convention, and that convention is any public method you add to a controller class is an action that can be accessed by a correctly formatted URL. The fact that Rails even can do this is testament to Ruby's dynamism. You can do crazy things like

~ > cat a.rb
class BaseClass
  def BaseClass::method_added methodname
    puts "<#{ methodname }> should be accessable"

class DerivedClass < BaseClass
  def an_added_method

~ > ruby a.rb
<an_added_method> should be accessable

and Rails leverages this from every angle.

LJ: You didn't write this controller from scratch, did you?

DF: You guessed it. The generate script also is used to generate your controller classes, web_services and so on. Typically, you simply generate the class and then start editing from there.

LJ: I understand that URLs are mapped to a method call on a controller object, but how does that finally end up spitting out HTML?

DF: The standard Rails HTML generating mechanism is the ERb template. ERb, as you know, stands for embedded Ruby, and it is a simple way to embed small pieces of Ruby code into HTML documents. So for each action in a controller, you typically would have a corresponding "view" consisting of an ERb/HTML template file (.rhtml) with the same name as the action.

LJ: And you have to set up some sort of data structure for the template to access?

DF: Not really. The view has access to the instance-variables of the controller. It's a lot like they are friend classes in that the instance-data simply is available in the view templates, as if it were in the same scope.

LJ: Then, rendering the view effectively works like a method call on the controller object--all of its internal state is available for the view to access?

DF: Pretty much.

LJ: I have some notion now that each table in your database is going to have a model and each page in your blog is going to have a controller and view class associated with it. The arrangement looks, more or less, like Figure 2. I'm wondering how many classes you ended up with, how many lines of code?

Figure 2. The Blog Arrangement

DF: Well, to get something working, it probably was between 400 and 600 lines of my own code and a half dozen controller-classes. But, that includes quite a few things such as authentication and administrative pages. Obviously, that number could be improved upon--I'm a Ruby newbie--but I'm happy with the codebase size.

LJ: Have people been liking your blog?

DF: I think people have liked it; I mean my programmer friends read it. It's nothing special, I'm not going to replace WordPress or blogger.com, but my buddies get a kick out of reading it and posting comments, and my parents are coming around slowly. I think people like it mainly because there are pictures of my daughter up there all the time.

LJ: What about your programmer friends? What has their reception been to you developing in Ruby on Rails?

DF: A lot of my friends have been really interested. Some of my friends who are in grad school have started to embrace Ruby for some of their projects. I even have a friend who wrote an iCal library in Ruby and now is planning on rewriting his own Web site using Rails.

LJ: But some big name developers out there seem to have had a fairly negative response to all the Rails hype. Why do you think that is?

DF: I think fear of any technology is not really based in reality, because what is technology after all? It's just another way of solving a problem. But I hear what you're saying, I've read some comments that I feel totally were not based on the facts. I think that some of it is probably due to people who really are invested in one framework or the other and maybe are afraid that Rails' momentum could threaten their authority or their opportunities if it were to take over a lot of market share in "web-app-framework-land". So there's that, and then there's the whole thing of if this becomes "the way to do it", then they'll have to start learning a whole new language and framework all over again.

LJ: Did you have a tough a time learning Ruby as you were learning Rails?

DF: No, I didn't.

LJ: I remember when you and I were doing a code walk-through the other day, and you said you didn't even know how to assign a hash element. I thought it was pretty amazing that you'd written an entire blog and didn't even know a language fundamental such as that one. It says something about the ways Rails was designed that you don't have to be a guru in the language to do a fairly complex Web application with it.

DF: Yeah, that's one of the things Rails has to offer: Ruby. That's awesome. People miss that point--the language is awesome. It's fun to write in. The Rails framework itself is fun too, and it's very fast to develop in.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Interesting article

Anonymous's picture

Thank you for the interesting article. We have considering using Ruby for various portions of our web to print solution.

Exploring Ruby on Rails

securenext's picture

Ruby on Rails or RoR, is an open source web application framework for the Ruby programming language.

We build quality Ruby On Rails web applications for startups and established businesses since early 2006. We focus on the core idea, perfect the interface, suggest innovative features and deliver; we help your company succeed faster by using the best technologies available.

Secure Next is a software technology corporation that develops, manufactures, and supports a wide range of software and web development projects. Headquartered in Fresno, California, USA, and its offshore in Chennai, India, we rock on every single projects we develop and venture into upcoming technology with a vision of agile web development & customer satisfaction.

Thus, we want to make people feel informed and involved, committing quality and timeliness and ready to flourish using latest technology. website: http://www.rordevelopers.com & http://www.securenext.com


jaysmith's picture

really liked the Q&A approach. This article was just what I needed as a newbie who is just getting started with RonR.

Thinking about ruby

Dinesh Sharma's picture

I think that ruby on Rails is an interesting language as well as faster then others but little bit confused that will i be able to develop any kind of application ?

Ruby - For Professionals

Computer Service Bonn's picture

Ruby reminds me on the forecast of gartner, that till 2010 there will be 40% less employment in information technology. The forecast bases on the fact, that productivity in IT increases dramatically. Ruby demonstrates another highly productive environment. It is not neccessary to learn anything, neither design pattern nor programming languages. For Doug Fales who is very experienced in Java, Ruby is a nice trip. But I would not begin with it.

Ruby on Rails Interview

JC's picture

Good job & very interesting!

I really liked the Q&A approach. This article was just what I needed as a newbie who is just getting started with RonR.

My development teams are JAVA and Coldfusion based. They are reluctant to consider RonR, but I am very impressed and will continue down this road.