Re: overriding on Rails: tables, foreign keys

[Jerome Hughes <jromeh@xxxxxxx>]

On Aug 21, 2006, at 7:51 AM, Joe Pluta wrote:

> Actually, I'd be surprised if you couldn't use the scaffold, since  
> it's such
> an intrinsic part of the tool.  (And of course you need the ID  
> field fix
> just to work with MySQL, which capitalizes the ID field name.)

Wouldn't say that the scaffold is such an intrisic part of the tool.  
It's really there just to get going, and most of it will be replaced  
in any user facing completed app. You can just run it (the magic  
part) or you can generate its code (and study it to learn how it  
works) but it seems most apps built by experienced developers are  
created by working with the model on the command line using script/ 
console and then building out views and controllers once it's getting  
solid.

The scaffold is a basic one table editor, and most real views require  
data from more than one table. This is handled in the model with  
relationships, and then controllers use the relationships to load  
variables that are passed out to the views for rendering. Just  
methods on objects, no SQL written, all of it generated based on the  
model. Believe there are better paging alternatives available or on  
the way, need to get more info on that.

Here's a good article on this area with some pointers to other  
resources...

http://www.slash7.com/articles/2005/12/07/the-fall-from-scaffolding

"The solution: You actually have to learn Rails."

> In general, Ruby seems quite capable of handling "non-conventional"
> environments through configuration.  And while the configuration is  
> in the
> code itself rather than in external files, the terseness of Ruby  
> code in
> general might ameliorate that particular issue.  I mean, it's not like
> there's a ton of code in any given ActiveRecord class, so sticking the
> configuration right in the code rather than in some non-typed XML  
> file can
> probably be argued to be a positive.

It's Rails that is doing this with Ruby code, finding as get deeper  
into it that basically everything is done in Ruby code, including  
defining the database using migrations, setting up test data with  
fixtures, etc. Ruby is a "meta-language" which allows the creation of  
domain specific sub-languages for handling these sorts of issues, the  
sub-language code is still in Ruby syntax, but with established  
conventions for handling the problem domain.

thx & hth,

--Jerome