Re: overriding on Rails: tables, foreign keys -- WEB400


On Aug 21, 2006, at 10:02 AM, Joe Pluta wrote:

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 explicitlydefinethe fields in the record, which is nice when you are only accessinga few

fields from the file.

Not yet sure if the generated SQL always gets all fields or not, willwatch for that, can see the SQL statements in the console as the appruns.

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 thereare a lotof valid academic reasons to use phrases like "domain-specificlanguage",Ruby isn't doing anything we don't do when we write Java classes oreven ILE
subroutines.  I can (and often do) define "conventions" when writing
applications: type 3 objects don't get inventory allocated,warehouse one isused for dropships, and so on. In fact when the name of somethingmagicallydetermines what it does, I tend to call that "hardcoding", notconvention.
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.


OK, sounds like didn't explain that as well as intended.

Rails is using the meta-language capabilities of Ruby when faced withthese sorts of challenges instead of going to an XML config file, soeverything stays in one language.

Have seen this mostly thus far in migrations and in fixtures but surethey are also in other places.

Migrations are for creating and adjusting table structures, theseprovide up and down methods that contain Ruby statements definingcolumns to get from present schema state to desired schema state andback in the other direction.

Fixtures are for auto-loading sample test data used in automatedtests each time those tests are run, which is each time rake is run.

So these are not things that developers using Rails are creating,necessarily, though they can, too, once understanding is in place,but things that they are using because the developers creating Railshave used them and they are now the way to go to get the developmenttasks done easily. Part of the structure, if you will.

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

Glad to see you're continuing to look at it, think you'll bepleasantly surprised as you get deeper.

Really don't know much about Python beyond the significant whitespace thing so many love to hate, but have an image that it's sort oflike PHP, in that it's a nice enough scripting language, but sort ofgeneral purpose, and so leaving many more architectural decisions tothe developer than RoR does, which can lead to a much wider range ofbad to good implementations. If the developer is experienced, expecta good structure and understandable code, otherwise it could beanything.

One of the advantages of Rails' opinionated approach may be that evenbeginners are guided toward a long-term maintainable structure.


thx & hth,

--Jerome