Day 2 on Ruby - Confused

rubyonrails-talk
1

Ok I admit , the screencasts and from what I have seen so far got me excited. I am an experienced PHP, C++, Assembly, etc programmer.

I have been around this block many times. I know you need to "pay your dues" before it "clicks".... ie. researching, tutorials, and awesome answers from groups like this.... :wink:

IN CONTEXT - Let's say we are talking about a site that caters to , ahm... roofers. Yeah, that should be a curve ball.

1. Am I understanding ROR correct ( high level ) where the index page, the estimate page, the job page, etc should have it's own controller? Have it's own view?

2. I read how ROR can magically map table names to classes. Cool. But what about when I have a SQL statement on a page that contains a ton of joins , group by, etc. ??

3. This one is really perplexing... I think I understand the app "layout". But what if I want to include the same header, but with some conditional logic in my css, such as "if we are on this page, then make this button's class "xyz". ?

4. Lastly, regarding the "migration".... I must say, it looks cool, but I cannot see how it would differ from someone like myself saving multiple sql files with version numbers, and dropping my db and creating a new one? Am I missing something?

Thanks!

Again... so excited!

2

Ok I admit , the screencasts and from what I have seen so far got me excited. I am an experienced PHP, C++, Assembly, etc programmer.

I have been around this block many times. I know you need to "pay your dues" before it "clicks".... ie. researching, tutorials, and awesome answers from groups like this.... :wink:

IN CONTEXT - Let's say we are talking about a site that caters to , ahm... roofers. Yeah, that should be a curve ball.

1. Am I understanding ROR correct ( high level ) where the index page, the estimate page, the job page, etc should have it's own controller? Have it's own view?

Broadly speaking yes.

2. I read how ROR can magically map table names to classes. Cool. But what about when I have a SQL statement on a page that contains a ton of joins , group by, etc. ??

First off, that statement would be in the relevant model, and while you can drop down to raw sql, you rarely need to. Activerecord will generate join statements and so on for you, eg Customer.find :all, :joins => [{:jobs => :items}, :support_incidents] will create the appropriate joins for those associations

3. This one is really perplexing... I think I understand the app "layout". But what if I want to include the same header, but with some conditional logic in my css, such as "if we are on this page, then make this button's class "xyz". ?

The layout is rendered in the same way as the rest of the templates, so for example your template could say

<div class="header <%= @page_type %>"> ...

In in your css you'd have

div.header.main { ... }

div.header.something_else{ ... }

You can also use content_for to have blocks of content inserted into the layout that are rendered by the controller.

4. Lastly, regarding the "migration".... I must say, it looks cool, but I cannot see how it would differ from someone like myself saving multiple sql files with version numbers, and dropping my db and creating a new one? Am I missing something?

That is essentially what a migration is except that a migration is written using activerecord's schema altering statemens, which are portable across databases, and of course you can run regular ruby code in your migration (eg to fix up data). If you were writing it yourself you'd also have to write the scripts that did things like track which migrations have already run, scripts that will rollback the specified number of versions etc...

Fred

3

Frederick Cheung wrote:

1. Am I understanding ROR correct ( high level ) where the index page, the estimate page, the job page, etc should have it's own controller? Have it's own view?

Broadly speaking yes.

More specifically speaking, you _can_ do it however you want to. If you _really_ wanted to, you could probably have one controller for the whole application. No one that frequents this forum would support such a decision though :slight_smile: Ideally, you would have one controller for each resource that your application manages, plus whatever other controllers you need for accessing non-resource related pages (such as index, contact_us, about_us, etc). In case you are unfamiliar with the term "resource" as it relates to web development, it's simply a thing that the user interacts with. It can be a person, a customer, a job, a business, a pencil, anything that gets listed (index), displayed (show), created (new/create), edited (edit/update) or deleted (destroy).

In your example, you'd have a general controller called "welcome" or something that serves up the index action. You would also have a jobs controller, an estimates controller, possibly a customers controller, etc.

When I first started in Rails, I was much less structured than I am now. I would have all kinds of wacky actions in a controller, and my controllers were generally pretty big (not quite fat, but definitely in need of some weight loss). I have since been more diligent about trying to be RESTful and give more thought to how I map resources to controllers. I have a lot more files now, but they are much simpler and easier to maintain. I have also come across a few situations in which I can subclass a controller to share code between resources that act almost exactly the same. It's pretty exciting to spend a day or two getting a bunch of functionality working for a particular resource and then "port" it to two or three other resources in 15 minutes.

Peace, Phillip

4

Other people have given good replies to your questions. :slight_smile: As for migrations, I've found them to be invaluable when developing in teams. Writing a migration file and telling the other team members to run 'rake db:migrate' is easier than telling each one of them "hey dude, I added this column to this table. oh and I renamed that column too. oh and this too" each time. Migrations are basically diffs of the database schema, written in Ruby syntax. That means that when using migrations, you don't have to destroy your existing data. And because it's Ruby, migrations can even perform complex data conversions.

It takes a little bit to get used to, that's all. I didn't use migrations until my 3rd Rails project or so.

Regards, Hongli Lai