David Christopher Zentgraf wrote:
Thanks for the detailed explanation.
Every tutorial I had a look at so far began with modelling the tables using SQL in one way or another and than building Rails on top of that, getting it to reference the correct tables. Apparently that's the wrong way to go...
If I can do all the references from A to B and vice-versa using classes in Rails I think I'll be happy.
Regarding that, what's actually the best way to start an application? Writing a migration, creating the DB from it, scaffolding the models and controllers, then doing the has_many :B, :C? Or will those relations be scaffolded automatically if I'm migrating correctly?
Chrs,
Dav
Hi David,
Rails/ Ruby are all about agility, so, the idea is to do frequent iterations, adding a little bit at each iteration.
I would start by creating a migration for one of the models and then creating the model for it. If I was eager to see what it looked like, I'd create a controller/ scaffold to get it up so that I can enter some things into the table. Then, I'd go after the next model and so on. Once both sides of a relationship exist, I'd add the relationships and add the view/ controller code for managing insertions, etc. (I haven't yet used ActivScaffold so I'm not full sure what all it handles).
The second edition of Agile Web Development with Rails does go through a full-fledged application at the start of the book. While it's a real-enough application, it opens up all the key features of Rails. If you decide to commit to Rails, it is a worthwhile investment. There's another book from SitePoint that is available free of charge right now (58 days and counting down) and it should cover the main concepts too.
Alternatively, look for online tutorials. There are a couple of IBM Developer Works which take you through your first application that are not bad, either.
Cheers,
Mohit.
10/4/2007 | 12:28 PM.