Re: overriding on Rails: tables, foreign keys

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Jerome Hughes
>
> 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.

I understand.  EGL does the same thing, except that you explicitly define
the fields in the record, which is nice when you are only accessing a few
fields from the file. 

> 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.

See, this is where I get off the bandwagon.  While I'm sure there are a lot
of valid academic reasons to use phrases like "domain-specific language",
Ruby isn't doing anything we don't do when we write Java classes or even ILE
subroutines.  I can (and often do) define "conventions" when writing
applications: type 3 objects don't get inventory allocated, warehouse one is
used for dropships, and so on.  In fact when the name of something magically
determines what it does, I tend to call that "hardcoding", not convention.

Personally, I'm not a big fan of magic, either in applications or in
languages.  I prefer my rules spelled out where I can see them.

But that won't stop me from taking a look at RoR to see where it does well.
Ror seems to have a bit more traction than Python, so we'll see if it
continues.

Joe