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…
IN CONTEXT - Let’s say we are talking about a site that caters to ,
ahm… roofers. Yeah, that should be a curve ball.
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?
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. ??
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”. ?
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?
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.
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
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
...
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.
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…
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 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.
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?
Other people have given good replies to your questions. 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 L.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Ideally, you would have one controller for each
As for